# SOME DESCRIPTIVE TITLE. # Copyright (C) 2015, OpenStack contributors # This file is distributed under the same license as the Networking Guide package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Networking Guide 0.9\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2016-07-15 09:10+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../adv-config-debugging.rst:3 msgid "Debugging" msgstr "" #: ../adv-config-debugging.rst:5 msgid "" "The OpenStack Networking service offers many degrees of freedom because of " "the pluggable back end that supports a variety of open source and vendor " "(proprietary) plug-ins. The open source plug-ins generally implement native " "Linux facilities such as Open vSwitch (OVS) and Linux bridge. This section " "provides methods to troubleshoot and mitigate network issues for " "environments using the open source ML2 plug-in with the OVS or Linux bridge " "agent." msgstr "" #: ../adv-config-debugging.rst:14 ../adv-config-debugging.rst:29 msgid "Neutron-debug command line tools" msgstr "" #: ../adv-config-debugging.rst:16 msgid "" "Network troubleshooting can unfortunately be a very difficult and confusing " "procedure. A network issue can cause a problem at several points in the " "cloud. Using a logical troubleshooting procedure can help mitigate the " "confusion and quickly isolate the network issue." msgstr "" #: ../adv-config-debugging.rst:21 msgid "" "Some of the following sections reference these popular tools to understand " "both network configuration and traffic patterns:" msgstr "" #: ../adv-config-debugging.rst:24 msgid "iproute2" msgstr "" #: ../adv-config-debugging.rst:25 msgid "tcpdump" msgstr "" #: ../adv-config-debugging.rst:26 msgid "iptables" msgstr "" #: ../adv-config-debugging.rst:31 ../adv-config-debugging.rst:36 #: ../adv-config-debugging.rst:41 ../adv-config-debugging.rst:46 #: ../adv-config-debugging.rst:51 ../adv-config-debugging.rst:56 msgid "Subsection ..." msgstr "" #: ../adv-config-debugging.rst:34 msgid "Network configuration in the database" msgstr "" #: ../adv-config-debugging.rst:39 msgid "Debugging DHCP Issues" msgstr "" #: ../adv-config-debugging.rst:44 msgid "Debugging DNS Issues" msgstr "" #: ../adv-config-debugging.rst:49 msgid "Network namespaces configuration" msgstr "" #: ../adv-config-debugging.rst:54 msgid "Summary" msgstr "" # #-#-#-#-# adv-config-fwaas.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-ipv6.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-fwaas.rst:3 ../adv-config-ipv6.rst:398 msgid "FWaaS" msgstr "" #: ../adv-config-fwaas.rst:5 msgid "See the following URL:" msgstr "" #: ../adv-config-fwaas.rst:7 msgid "" "http://docs.openstack.org/admin-guide-cloud/networking_introduction." "html#firewall-as-a-service-fwaas-overview" msgstr "" #: ../adv-config-group-policy.rst:3 msgid "Group policy" msgstr "" # #-#-#-#-# adv-config-group-policy.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-operational.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-service-chaining.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-vpnaas.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# migration-classic-to-dvr.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-group-policy.rst:5 ../adv-config-group-policy.rst:12 #: ../adv-config-operational.rst:5 ../adv-config-service-chaining.rst:7 #: ../adv-config-vpnaas.rst:5 ../migration-classic-to-dvr.rst:5 msgid "TBD" msgstr "" #: ../adv-config-group-policy.rst:9 msgid "How it differs from legacy neutron data model" msgstr "" #: ../adv-config-ipam.rst:3 msgid "IPAM configuration" msgstr "" #: ../adv-config-ipam.rst:5 msgid "" "Starting with the Liberty release, OpenStack Networking includes a pluggable " "interface for the IP Address Management (IPAM) function. This interface " "creates a driver framework for the allocation and de-allocation of subnets " "and IP addresses, enabling the integration of alternate IPAM implementations " "or third-party IP Address Management systems." msgstr "" # #-#-#-#-# adv-config-ipam.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-ipv6.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-qos.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-sriov.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-ipam.rst:12 ../adv-config-ipv6.rst:12 #: ../adv-config-qos.rst:23 ../adv-config-sriov.rst:11 msgid "The basics" msgstr "" #: ../adv-config-ipam.rst:14 msgid "" "The IPAM implementation within OpenStack Networking provides two basic " "flavors (pluggable IPAM, non-pluggable IPAM). By default, the non-pluggable " "IPAM is enabled. This provides backward compatibility with older releases. " "In contrast, the pluggable implementation will require a database migration " "to support upgraded systems. This migration is planned for the Mitaka " "release." msgstr "" #: ../adv-config-ipam.rst:20 msgid "" "The reference driver for the pluggable implementation is considered " "experimental at this time. It does not provide additional functionality " "beyond the non-pluggable implementation, but does provide a basis for custom " "or third-party developed drivers. This can enable, for example, development " "of drivers that use different algorithms to allocate an IP address." msgstr "" #: ../adv-config-ipam.rst:26 msgid "" "To enable the pluggable implementation, you must specify the driver to use " "in the ``neutron.conf`` file. The ``internal`` driver refers to the " "reference implementation." msgstr "" #: ../adv-config-ipam.rst:34 msgid "" "The documentation for any alternate drivers will include the value to use " "when specifying that driver." msgstr "" # #-#-#-#-# adv-config-ipam.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-sriov.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-ipam.rst:38 ../adv-config-sriov.rst:65 msgid "Known limitations" msgstr "" #: ../adv-config-ipam.rst:40 msgid "" "The driver interface is designed to allow separate drivers for each subnet " "pool. However, the current implementation allows only a single IPAM driver " "system-wide." msgstr "" #: ../adv-config-ipam.rst:43 msgid "" "Database migrations are not available to convert existing OpenStack " "installations to the new reference implementation of the pluggable IPAM. " "This migration is planned for the Mitaka release." msgstr "" #: ../adv-config-ipam.rst:46 msgid "" "Third-party drivers must provide their own migration mechanisms to convert " "existing OpenStack installations to their IPAM." msgstr "" #: ../adv-config-ipv6.rst:3 msgid "Using OpenStack Networking with IPv6" msgstr "" #: ../adv-config-ipv6.rst:5 msgid "" "The purpose of this page is to describe how the features and functionality " "available in OpenStack (using neutron networking) as of the Kilo release. It " "is intended to serve as a guide for how to deploy IPv6-enabled instances " "using OpenStack Networking. Where appropriate, features planned for Liberty " "or beyond may be described." msgstr "" #: ../adv-config-ipv6.rst:14 msgid "" "OpenStack Networking has supported IPv6 tenant subnets in certain " "configurations since Juno, but later releases added a number of new " "features, functionality and bug fixes to make it more robust. The focus of " "this page will be:" msgstr "" #: ../adv-config-ipv6.rst:19 msgid "How to enable dual-stack (IPv4 and IPv6 enabled) instances." msgstr "" #: ../adv-config-ipv6.rst:20 msgid "How those instances receive an IPv6 address." msgstr "" #: ../adv-config-ipv6.rst:21 msgid "" "How those instances communicate across a router to other subnets or the " "internet." msgstr "" #: ../adv-config-ipv6.rst:23 msgid "How those instances interact with other OpenStack services." msgstr "" #: ../adv-config-ipv6.rst:25 msgid "" "To enable a dual-stack network in OpenStack Networking simply requires " "creating a subnet with the ``ip_version`` field set to ``6``, then the IPv6 " "attributes (``ipv6_ra_mode`` and ``ipv6_address_mode``) set. The " "``ipv6_ra_mode`` and ``ipv6_address_mode`` will be described in detail in " "the next section. Finally, the subnets ``cidr`` needs to be provided." msgstr "" #: ../adv-config-ipv6.rst:32 msgid "Not in scope" msgstr "" #: ../adv-config-ipv6.rst:34 msgid "Things not in the scope of this document include:" msgstr "" #: ../adv-config-ipv6.rst:36 msgid "Single stack IPv6 tenant networking" msgstr "" #: ../adv-config-ipv6.rst:37 msgid "" "OpenStack control communication between servers and services over an IPv6 " "network." msgstr "" #: ../adv-config-ipv6.rst:39 msgid "Connection to the OpenStack APIs via an IPv6 transport network" msgstr "" #: ../adv-config-ipv6.rst:40 msgid "IPv6 multicast" msgstr "" #: ../adv-config-ipv6.rst:41 msgid "" "IPv6 support in conjunction with any out of tree routers, switches, services " "or agents whether in physical or virtual form factors." msgstr "" #: ../adv-config-ipv6.rst:46 msgid "Neutron subnets and the IPv6 API attributes" msgstr "" #: ../adv-config-ipv6.rst:48 msgid "" "As of Juno, the OpenStack Networking service (neutron) provides two new " "attributes to the subnet object, which allows users of the API to configure " "IPv6 subnets." msgstr "" #: ../adv-config-ipv6.rst:52 msgid "There are two IPv6 attributes:" msgstr "" #: ../adv-config-ipv6.rst:54 msgid "``ipv6_ra_mode``" msgstr "" #: ../adv-config-ipv6.rst:55 msgid "``ipv6_address_mode``" msgstr "" #: ../adv-config-ipv6.rst:57 msgid "These attributes can be set to the following values:" msgstr "" #: ../adv-config-ipv6.rst:59 msgid "``slaac``" msgstr "" #: ../adv-config-ipv6.rst:60 msgid "``dhcpv6-stateful``" msgstr "" #: ../adv-config-ipv6.rst:61 msgid "``dhcpv6-stateless``" msgstr "" #: ../adv-config-ipv6.rst:63 msgid "The attributes can also be left unset." msgstr "" #: ../adv-config-ipv6.rst:67 msgid "IPv6 addressing" msgstr "" #: ../adv-config-ipv6.rst:70 msgid "" "The ``ipv6_address_mode`` attribute is used to control how addressing is " "handled by OpenStack. There are a number of different ways that guest " "instances can obtain an IPv6 address, and this attribute exposes these " "choices to users of the Networking API." msgstr "" #: ../adv-config-ipv6.rst:77 msgid "Router advertisements" msgstr "" #: ../adv-config-ipv6.rst:79 msgid "" "The ``ipv6_ra_mode`` attribute is used to control router advertisements for " "a subnet." msgstr "" #: ../adv-config-ipv6.rst:82 msgid "" "The IPv6 Protocol uses Internet Control Message Protocol packets (ICMPv6) as " "a way to distribute information about networking. ICMPv6 packets with the " "type flag set to 134 are called \"Router Advertisement\" packets, which " "broadcasts information about the router and the route that can be used by " "guest instances to send network traffic." msgstr "" #: ../adv-config-ipv6.rst:89 msgid "" "The ``ipv6_ra_mode`` is used to specify if the Networking service should " "transmit ICMPv6 packets, for a subnet." msgstr "" #: ../adv-config-ipv6.rst:93 msgid "ipv6_ra_mode and ipv6_address_mode combinations" msgstr "" #: ../adv-config-ipv6.rst:99 msgid "ipv6 ra mode" msgstr "" #: ../adv-config-ipv6.rst:100 msgid "ipv6 address mode" msgstr "" #: ../adv-config-ipv6.rst:101 msgid "radvd A,M,O" msgstr "" #: ../adv-config-ipv6.rst:102 msgid "External Router A,M,O" msgstr "" #: ../adv-config-ipv6.rst:103 msgid "Description" msgstr "" #: ../adv-config-ipv6.rst:104 ../adv-config-ipv6.rst:105 #: ../adv-config-ipv6.rst:109 ../adv-config-ipv6.rst:114 #: ../adv-config-ipv6.rst:119 ../adv-config-ipv6.rst:125 #: ../adv-config-ipv6.rst:130 ../adv-config-ipv6.rst:135 msgid "*N/S*" msgstr "" #: ../adv-config-ipv6.rst:106 ../adv-config-ipv6.rst:111 #: ../adv-config-ipv6.rst:116 ../adv-config-ipv6.rst:121 #: ../adv-config-ipv6.rst:127 ../adv-config-ipv6.rst:132 #: ../adv-config-ipv6.rst:137 ../adv-config-ipv6.rst:142 #: ../adv-config-ipv6.rst:147 ../adv-config-ipv6.rst:153 msgid "Off" msgstr "" #: ../adv-config-ipv6.rst:107 msgid "Not Defined" msgstr "" #: ../adv-config-ipv6.rst:108 msgid "Backwards compatibility with pre-Juno IPv6 behavior." msgstr "" #: ../adv-config-ipv6.rst:110 ../adv-config-ipv6.rst:124 #: ../adv-config-ipv6.rst:139 ../adv-config-ipv6.rst:140 #: ../adv-config-ipv6.rst:157 ../adv-config-ipv6.rst:162 #: ../adv-config-ipv6.rst:168 ../adv-config-ipv6.rst:178 msgid "slaac" msgstr "" #: ../adv-config-ipv6.rst:112 ../adv-config-ipv6.rst:126 #: ../adv-config-ipv6.rst:141 msgid "1,0,0" msgstr "" #: ../adv-config-ipv6.rst:113 msgid "" "Guest instance obtains IPv6 address from non-OpenStack router using SLAAC." msgstr "" #: ../adv-config-ipv6.rst:115 ../adv-config-ipv6.rst:129 #: ../adv-config-ipv6.rst:144 ../adv-config-ipv6.rst:145 #: ../adv-config-ipv6.rst:158 ../adv-config-ipv6.rst:167 #: ../adv-config-ipv6.rst:172 ../adv-config-ipv6.rst:183 msgid "dhcpv6-stateful" msgstr "" #: ../adv-config-ipv6.rst:117 ../adv-config-ipv6.rst:131 #: ../adv-config-ipv6.rst:146 msgid "0,1,1" msgstr "" #: ../adv-config-ipv6.rst:118 ../adv-config-ipv6.rst:123 #: ../adv-config-ipv6.rst:128 ../adv-config-ipv6.rst:133 #: ../adv-config-ipv6.rst:138 msgid "Not currently implemented in the reference implementation." msgstr "" #: ../adv-config-ipv6.rst:120 ../adv-config-ipv6.rst:134 #: ../adv-config-ipv6.rst:150 ../adv-config-ipv6.rst:151 #: ../adv-config-ipv6.rst:163 ../adv-config-ipv6.rst:173 #: ../adv-config-ipv6.rst:177 ../adv-config-ipv6.rst:182 msgid "dhcpv6-stateless" msgstr "" #: ../adv-config-ipv6.rst:122 ../adv-config-ipv6.rst:136 #: ../adv-config-ipv6.rst:152 msgid "1,0,1" msgstr "" #: ../adv-config-ipv6.rst:143 msgid "" "Guest instance obtains IPv6 address from OpenStack managed radvd using SLAAC." msgstr "" #: ../adv-config-ipv6.rst:148 msgid "" "Guest instance obtains IPv6 address from dnsmasq using DHCPv6 stateful and " "optional info from dnsmasq using DHCPv6." msgstr "" #: ../adv-config-ipv6.rst:154 msgid "" "Guest instance obtains IPv6 address from OpenStack managed radvd using SLAAC " "and optional info from dnsmasq using DHCPv6." msgstr "" #: ../adv-config-ipv6.rst:161 ../adv-config-ipv6.rst:166 #: ../adv-config-ipv6.rst:171 ../adv-config-ipv6.rst:176 #: ../adv-config-ipv6.rst:181 ../adv-config-ipv6.rst:186 msgid "*Invalid combination.*" msgstr "" #: ../adv-config-ipv6.rst:189 msgid "Tenant network considerations" msgstr "" #: ../adv-config-ipv6.rst:192 msgid "Dataplane" msgstr "" #: ../adv-config-ipv6.rst:194 msgid "" "Both the Linux bridge and the Open vSwitch dataplane modules support " "forwarding IPv6 packets amongst the guests and router ports. Similar to " "IPv4, there is no special configuration or setup required to enable the " "dataplane to properly forward packets from the source to the destination " "using IPv6. Note that these dataplanes will forward Link-local Address (LLA) " "packets between hosts on the same network just fine without any " "participation or setup by OpenStack components after the ports are all " "connected and MAC addresses learned." msgstr "" #: ../adv-config-ipv6.rst:204 msgid "Addresses for subnets" msgstr "" #: ../adv-config-ipv6.rst:206 msgid "There are four methods for a subnet to get its ``cidr`` in OpenStack:" msgstr "" #: ../adv-config-ipv6.rst:208 msgid "Direct assignment during subnet creation via command line or Horizon" msgstr "" #: ../adv-config-ipv6.rst:209 msgid "Referencing a subnet pool during subnet creation" msgstr "" #: ../adv-config-ipv6.rst:211 msgid "" "In the future, different techniques could be used to allocate subnets to " "tenants:" msgstr "" #: ../adv-config-ipv6.rst:214 msgid "Using a PD client to request a prefix for a subnet from a PD server" msgstr "" #: ../adv-config-ipv6.rst:215 msgid "Use of an external IPAM module to allocate the subnet" msgstr "" #: ../adv-config-ipv6.rst:218 msgid "Address modes for ports" msgstr "" #: ../adv-config-ipv6.rst:220 msgid "" "That an external DHCPv6 server in theory could override the full address " "OpenStack assigns based on the EUI-64 address, but that would not be wise as " "it would not be consistent through the system." msgstr "" #: ../adv-config-ipv6.rst:224 msgid "" "IPv6 supports three different addressing schemes for address configuration " "and for providing optional network information." msgstr "" #: ../adv-config-ipv6.rst:228 msgid "Address configuration using Router Advertisement (RA)." msgstr "" #: ../adv-config-ipv6.rst:228 msgid "Stateless Address Auto Configuration (SLAAC)" msgstr "" #: ../adv-config-ipv6.rst:231 msgid "Address configuration using RA and optional information using DHCPv6." msgstr "" #: ../adv-config-ipv6.rst:232 ../adv-config-ipv6.rst:305 #: ../adv-config-ipv6.rst:306 msgid "DHCPv6-stateless" msgstr "" #: ../adv-config-ipv6.rst:235 msgid "Address configuration and optional information using DHCPv6." msgstr "" #: ../adv-config-ipv6.rst:235 ../adv-config-ipv6.rst:309 #: ../adv-config-ipv6.rst:310 msgid "DHCPv6-stateful" msgstr "" #: ../adv-config-ipv6.rst:237 msgid "" "OpenStack can be setup such that OpenStack Networking directly provides RA, " "DHCP relay and DHCPv6 address and optional information for their networks or " "this can be delegated to external routers and services based on the drivers " "that are in use. There are two neutron subnet attributes - ``ipv6_ra_mode`` " "and ``ipv6_address_mode`` – that determine how IPv6 addressing and network " "information is provided to tenant instances:" msgstr "" #: ../adv-config-ipv6.rst:245 msgid "``ipv6_ra_mode``: Determines who sends RA." msgstr "" #: ../adv-config-ipv6.rst:246 msgid "" "``ipv6_address_mode``: Determines how instances obtain IPv6 address, default " "gateway, or optional information." msgstr "" #: ../adv-config-ipv6.rst:249 msgid "" "For the above two attributes to be effective, ``enable_dhcp`` of the subnet " "object must be set to True." msgstr "" #: ../adv-config-ipv6.rst:253 msgid "Using SLAAC for addressing" msgstr "" #: ../adv-config-ipv6.rst:255 msgid "" "When using SLAAC, the currently supported combinations for ``ipv6_ra_mode`` " "and ``ipv6_address_mode`` are as follows." msgstr "" #: ../adv-config-ipv6.rst:262 ../adv-config-ipv6.rst:302 msgid "ipv6_ra_mode" msgstr "" #: ../adv-config-ipv6.rst:263 ../adv-config-ipv6.rst:303 msgid "ipv6_address_mode" msgstr "" #: ../adv-config-ipv6.rst:264 ../adv-config-ipv6.rst:304 msgid "Result" msgstr "" #: ../adv-config-ipv6.rst:265 msgid "Not specified." msgstr "" #: ../adv-config-ipv6.rst:266 ../adv-config-ipv6.rst:269 #: ../adv-config-ipv6.rst:270 msgid "SLAAC" msgstr "" #: ../adv-config-ipv6.rst:267 msgid "" "Addresses are assigned using EUI-64, and an external router will be used for " "routing." msgstr "" #: ../adv-config-ipv6.rst:271 msgid "" "Address are assigned using EUI-64, and OpenStack Networking provides routing." msgstr "" #: ../adv-config-ipv6.rst:274 msgid "" "Setting ``ipv6_ra_mode`` to ``slaac`` will result in OpenStack Networking " "routers being configured to send RA packets, when they are created. This " "results in the following values set for the address configuration flags in " "the RA messages:" msgstr "" #: ../adv-config-ipv6.rst:279 ../adv-config-ipv6.rst:320 msgid "Auto Configuration Flag = 1" msgstr "" #: ../adv-config-ipv6.rst:280 ../adv-config-ipv6.rst:321 msgid "Managed Configuration Flag = 0" msgstr "" #: ../adv-config-ipv6.rst:281 msgid "Other Configuration Flag = 0" msgstr "" #: ../adv-config-ipv6.rst:283 msgid "" "New or existing Neutron networks that contain a SLAAC enabled IPv6 subnet " "will result in all neutron ports attached to the network receiving IPv6 " "addresses. This is because when RA broadcast messages are sent out on a " "neutron network, they are received by all IPv6 capable ports on the network, " "and each port will then configure an IPv6 address based on the information " "contained in the RA packet. In some cases, an IPv6 SLAAC address will be " "added to a port, in addition to other IPv4 and IPv6 addresses that the port " "already has been assigned." msgstr "" #: ../adv-config-ipv6.rst:293 msgid "DHCPv6" msgstr "" #: ../adv-config-ipv6.rst:295 msgid "" "For DHCPv6-stateless, the currently supported combinations are as follows:" msgstr "" #: ../adv-config-ipv6.rst:307 msgid "" "Address and optional information using neutron router and DHCP " "implementation respectively." msgstr "" #: ../adv-config-ipv6.rst:311 msgid "Addresses and optional information are assigned using DHCPv6." msgstr "" #: ../adv-config-ipv6.rst:313 msgid "" "Setting DHCPv6-stateless for ``ipv6_ra_mode`` configures the neutron router " "with radvd agent to send RAs. The table below captures the values set for " "the address configuration flags in the RA packet in this scenario. " "Similarly, setting DHCPv6-stateless for ``ipv6_address_mode`` configures " "neutron DHCP implementation to provide the additional network information." msgstr "" #: ../adv-config-ipv6.rst:322 msgid "Other Configuration Flag = 1" msgstr "" #: ../adv-config-ipv6.rst:325 msgid "Router support" msgstr "" #: ../adv-config-ipv6.rst:327 msgid "" "The behavior of the neutron router for IPv6 is different than IPv4 in a few " "ways." msgstr "" #: ../adv-config-ipv6.rst:330 msgid "" "Internal router ports, that act as default gateway ports for a network, will " "share a common port for all IPv6 subnets associated with the network. This " "implies that there will be an IPv6 internal router interface with multiple " "IPv6 addresses from each of the IPv6 subnets associated with the network and " "a separate IPv4 internal router interface for the IPv4 subnet. On the other " "hand, external router ports are allowed to have a dual-stack configuration " "with both an IPv4 and an IPv6 address assigned to them." msgstr "" #: ../adv-config-ipv6.rst:338 msgid "" "Neutron tenant networks that are assigned Global Unicast Address (GUA) " "prefixes and addresses don’t require NAT on the neutron router external " "gateway port to access the outside world. As a consequence of the lack of " "NAT the external router port doesn’t require a GUA to send and receive to " "the external networks. This implies a GUA IPv6 subnet prefix is not " "necessarily needed for the neutron external network. By default, a IPv6 LLA " "associated with the external gateway port can be used for routing purposes. " "To handle this scenario, the implementation of router-gateway-set API in " "neutron has been modified so that an IPv6 subnet is not required for the " "external network that is associated with the neutron router. The LLA address " "of the upstream router can be learned in two ways." msgstr "" #: ../adv-config-ipv6.rst:350 msgid "" "In the absence of an upstream RA support, ``ipv6_gateway`` flag can be set " "with the external router gateway LLA in the neutron L3 agent configuration " "file. This also requires that no subnet is associated with that port." msgstr "" #: ../adv-config-ipv6.rst:353 msgid "" "The upstream router can send an RA and the neutron router will automatically " "learn the next-hop LLA, provided again that no subnet is assigned and the " "``ipv6_gateway`` flag is not set." msgstr "" #: ../adv-config-ipv6.rst:357 msgid "" "Effectively the ``ipv6_gateway`` flag takes precedence over an RA that is " "received from the upstream router. If it is desired to use a GUA next hop " "that is accomplished by allocating a subnet to the external router port and " "assigning the upstream routers GUA address as the gateway for the subnet." msgstr "" #: ../adv-config-ipv6.rst:363 msgid "" "That it should be possible for tenants to communicate with each other on an " "isolated network (a network without a router port) using LLA with little to " "no participation on the part of OpenStack. The authors of this section have " "not proven that to be true for all scenarios." msgstr "" #: ../adv-config-ipv6.rst:369 msgid "Neutron's Distributed Router feature and IPv6" msgstr "" #: ../adv-config-ipv6.rst:371 msgid "" "IPv6 does work when the Distributed Virtual Router functionality is enabled, " "but all ingress/egress traffic is via the centralized router (hence, not " "distributed). More work is required to fully enable this functionality." msgstr "" #: ../adv-config-ipv6.rst:377 msgid "Advanced services" msgstr "" # #-#-#-#-# adv-config-ipv6.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-vpnaas.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-ipv6.rst:380 ../adv-config-vpnaas.rst:3 #: ../intro-os-networking-service.rst:69 msgid "VPNaaS" msgstr "" #: ../adv-config-ipv6.rst:382 msgid "" "VPNaaS supports IPv6, but support in Kilo and prior releases will have some " "bugs that may limit how it can be used. More thorough and complete testing " "and bug fixing is being done as part of the Liberty release. IPv6-based VPN-" "as-a-Service is configured similar to the IPv4 configuration. Either or both " "the ``peer_address`` and the ``peer_cidr`` can specified as an IPv6 address. " "The choice of addressing modes and router modes described above should not " "impact support." msgstr "" #: ../adv-config-ipv6.rst:393 msgid "LBaaS" msgstr "" #: ../adv-config-ipv6.rst:395 msgid "TODO" msgstr "" #: ../adv-config-ipv6.rst:400 msgid "FWaaS allows creation of IPv6 based rules." msgstr "" #: ../adv-config-ipv6.rst:403 msgid "NAT & Floating IPs" msgstr "" #: ../adv-config-ipv6.rst:405 msgid "" "At the current time OpenStack Networking does not provide any facility to " "support any flavor of NAT with IPv6. Unlike IPv4 there is no current " "embedded support for floating IPs with IPv6. It is assumed that the IPv6 " "addressing amongst the tenants are using GUAs with no overlap across the " "tenants." msgstr "" #: ../adv-config-ipv6.rst:412 msgid "Security considerations" msgstr "" #: ../adv-config-ipv6.rst:418 msgid "Configuring interfaces of the guest" msgstr "" #: ../adv-config-ipv6.rst:420 msgid "" "OpenStack currently doesn't support the privacy extensions defined by RFC " "4941. The interface identifier and DUID used must be directly derived from " "the MAC as described in RFC 2373. The compute hosts must not be setup to " "utilize the privacy extensions when generating their interface identifier." msgstr "" #: ../adv-config-ipv6.rst:425 msgid "" "There is no provisions for an IPv6-based metadata service similar to what is " "provided for IPv4. In the case of dual stack Guests though it is always " "possible to use the IPv4 metadata service instead." msgstr "" #: ../adv-config-ipv6.rst:429 msgid "" "Unlike IPv4 the MTU of a given network can be conveyed in the RA messages " "sent by the router and not in the DHCP messages. In Kilo the MTU sent by " "RADVD is always 1500, but in Liberty changes are planned to allow the RA to " "send the proper MTU of the network." msgstr "" #: ../adv-config-ipv6.rst:435 msgid "OpenStack control & management network considerations" msgstr "" #: ../adv-config-ipv6.rst:437 msgid "" "As of the Kilo release, considerable effort has gone in to ensuring the " "tenant network can handle dual stack IPv6 and IPv4 transport across the " "variety of configurations describe above. This same level of scrutiny has " "not been apply to running the OpenStack control network in a dual stack " "configuration. Similarly, little scrutiny has gone into ensuring that the " "OpenStack API endpoints can be accessed via an IPv6 network. At this time, " "Open vSwitch (OVS) tunnel types - STT, VXLAN, GRE, only support IPv4 " "endpoints, not IPv6, so a full IPv6-only deployment is not possible with " "that technology." msgstr "" #: ../adv-config-ipv6.rst:449 msgid "Prefix delegation" msgstr "" #: ../adv-config-ipv6.rst:451 msgid "" "From the Liberty release onwards, OpenStack Networking supports IPv6 prefix " "delegation. This section describes the configuration and workflow steps " "necessary to use IPv6 prefix delegation to provide automatic allocation of " "subnet CIDRs. This allows you as the OpenStack administrator to rely on an " "external (to the OpenStack Networking service) DHCPv6 server to manage your " "tenant network prefixes." msgstr "" #: ../adv-config-ipv6.rst:459 msgid "" "Prefix delegation became available in the Liberty release, it is not " "available in the Kilo release. HA and DVR routers are not currently " "supported by this feature." msgstr "" #: ../adv-config-ipv6.rst:464 msgid "Configuring OpenStack Networking for prefix delegation" msgstr "" #: ../adv-config-ipv6.rst:466 msgid "" "To enable prefix delegation, edit the :file:`etc/neutron.conf` file. If you " "are running OpenStack Liberty, make the following change::" msgstr "" #: ../adv-config-ipv6.rst:471 msgid "Otherwise if you are running OpenStack Mitaka, make this change::" msgstr "" #: ../adv-config-ipv6.rst:477 msgid "" "If you are not using the default dibbler-based driver for prefix delegation, " "then you also need to set the driver in :file:`etc/neutron.conf`::" msgstr "" #: ../adv-config-ipv6.rst:483 msgid "" "Drivers other than the default one may require extra configuration, please " "refer to :ref:`extra-driver-conf`" msgstr "" #: ../adv-config-ipv6.rst:486 msgid "" "This tells OpenStack Networking to use the prefix delegation mechanism for " "subnet allocation when the user does not provide a CIDR or subnet pool id " "when creating a subnet." msgstr "" #: ../adv-config-ipv6.rst:491 msgid "Requirements" msgstr "" #: ../adv-config-ipv6.rst:493 msgid "" "To use this feature, you need a prefix delegation capable DHCPv6 server that " "is reachable from your OpenStack Networking node(s). This could be software " "running on the OpenStack Networking node(s) or elsewhere, or a physical " "router. For the purposes of this guide we are using the open-source DHCPv6 " "server, Dibbler. Dibbler is available in many Linux package managers, or " "from source at https://github.com/tomaszmrugalski/dibbler." msgstr "" #: ../adv-config-ipv6.rst:500 msgid "" "When using the reference implementation of the OpenStack Networking prefix " "delegation driver, Dibbler must also be installed on your OpenStack " "Networking node(s) to serve as a DHCPv6 client. Version 1.0.1 or higher is " "required." msgstr "" #: ../adv-config-ipv6.rst:504 msgid "" "This guide assumes that you are running a Dibbler server on the network node " "where the external network bridge exists. If you already have a prefix " "delegation capable DHCPv6 server in place, then you can skip the following " "section." msgstr "" #: ../adv-config-ipv6.rst:510 msgid "Configuring the Dibbler server" msgstr "" #: ../adv-config-ipv6.rst:512 msgid "" "After installing Dibbler, edit the :file:`/etc/dibbler/server.conf` file:" msgstr "" #: ../adv-config-ipv6.rst:525 msgid "The options used in the configuration file above are:" msgstr "" #: ../adv-config-ipv6.rst:527 msgid "" ":code:`script`: Points to a script to be run when a prefix is delegated or " "released. This is only needed if you want instances on your subnets to have " "external network access. More on this below." msgstr "" #: ../adv-config-ipv6.rst:530 msgid "" ":code:`iface`: The name of the network interface on which to listen for " "prefix delegation messages." msgstr "" #: ../adv-config-ipv6.rst:532 msgid "" ":code:`pd-pool`: The larger prefix from which you want your delegated " "prefixes to come. The example given is sufficient if you do not need " "external network access, otherwise a unique globally routable prefix is " "necessary." msgstr "" #: ../adv-config-ipv6.rst:536 msgid "" ":code:`pd-length`: The length that delegated prefixes will be. This must be " "64 to work with the current OpenStack Networking reference implementation." msgstr "" #: ../adv-config-ipv6.rst:539 msgid "" "To provide external network access to your instances, your Dibbler server " "also needs to create new routes for each delegated prefix. This is done " "using the script file named in the config file above. Edit the :file:`/var/" "lib/dibbler/pd-server.sh` file:" msgstr "" #: ../adv-config-ipv6.rst:555 msgid "The variables used in the script file above are:" msgstr "" #: ../adv-config-ipv6.rst:557 msgid ":code:`$PREFIX1`: The prefix being added/deleted by the Dibbler server." msgstr "" #: ../adv-config-ipv6.rst:558 msgid ":code:`$1`: The operation being performed." msgstr "" #: ../adv-config-ipv6.rst:559 msgid ":code:`$REMOTE_ADDR`: The IP address of the requesting Dibbler client." msgstr "" #: ../adv-config-ipv6.rst:560 msgid "" ":code:`$IFACE`: The network interface upon which the request was received." msgstr "" #: ../adv-config-ipv6.rst:563 msgid "" "The above is all you need in this scenario, but more information on " "installing, configuring, and running Dibbler is available in the Dibbler " "user guide, at http://klub.com.pl/dhcpv6/doc/dibbler-user.pdf." msgstr "" #: ../adv-config-ipv6.rst:567 msgid "To start your Dibbler server, run::" msgstr "" #: ../adv-config-ipv6.rst:571 msgid "Or to run in headless mode::" msgstr "" #: ../adv-config-ipv6.rst:575 msgid "" "When using DevStack, it is important to start your server after the :file:" "`stack.sh` script has finished to ensure that the required network " "interfaces have been created." msgstr "" # #-#-#-#-# adv-config-ipv6.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# adv-config-qos.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-ipv6.rst:580 ../adv-config-qos.rst:99 msgid "User workflow" msgstr "" #: ../adv-config-ipv6.rst:582 msgid "First, create a network and IPv6 subnet:" msgstr "" #: ../adv-config-ipv6.rst:624 msgid "" "The subnet is initially created with a temporary CIDR before one can be " "assigned by prefix delegation. Any number of subnets with this temporary " "CIDR can exist without raising an overlap error. The subnetpool_id is " "automatically set to :code:`prefix_delegation`." msgstr "" #: ../adv-config-ipv6.rst:629 msgid "" "To trigger the prefix delegation process, create a router interface between " "this subnet and a router with an active interface on the external network:" msgstr "" #: ../adv-config-ipv6.rst:639 msgid "" "The prefix delegation mechanism then sends a request via the external " "network to your prefix delegation server, which replies with the delegated " "prefix. The subnet is then updated with the new prefix, including issuing " "new IP addresses to all ports:" msgstr "" #: ../adv-config-ipv6.rst:667 msgid "" "If the prefix delegation server is configured to delegate globally routable " "prefixes and setup routes, then any instance with a port on this subnet " "should now have external network access." msgstr "" #: ../adv-config-ipv6.rst:671 msgid "" "Deleting the router interface causes the subnet to be reverted to the " "temporary CIDR, and all ports have their IPs updated. Prefix leases are " "released and renewed automatically as necessary." msgstr "" #: ../adv-config-ipv6.rst:676 msgid "References" msgstr "" #: ../adv-config-ipv6.rst:678 msgid "" "The following link provides a great step by step tutorial on setting up IPv6 " "with OpenStack: http://www.debug-all.com/?p=52" msgstr "" #: ../adv-config-ipv6.rst:684 msgid "Extra configuration" msgstr "" #: ../adv-config-ipv6.rst:687 msgid "Neutron dhcpv6_pd_agent" msgstr "" #: ../adv-config-ipv6.rst:688 msgid "" "To enable the driver for the dhcpv6_pd_agent, set pd_dhcp_driver to this in :" "file:`etc/neutron.conf`::" msgstr "" #: ../adv-config-ipv6.rst:693 msgid "" "To allow the neutron-pd-agent to communicate with prefix delegation servers, " "you must set which network interface to use for external communication. In " "DevStack the default for this is br-ex::" msgstr "" #: ../adv-config-ipv6.rst:699 msgid "" "Once you have stacked run the command below to start the neutron-pd-agent::" msgstr "" #: ../adv-config-lbaas.rst:3 msgid "Load Balancer as a Service (LBaaS)" msgstr "" #: ../adv-config-lbaas.rst:5 msgid "" "The Networking service offers two load balancer implementations through the " "``neutron-lbaas`` service plug-in:" msgstr "" #: ../adv-config-lbaas.rst:8 msgid "LBaaS v1: introduced in Juno (deprecated in Liberty)" msgstr "" #: ../adv-config-lbaas.rst:9 msgid "LBaaS v2: introduced in Kilo" msgstr "" #: ../adv-config-lbaas.rst:11 msgid "" "Both implementations use agents. The agents handle the HAProxy configuration " "and manage the HAProxy daemon. LBaaS v2 adds the concept of listeners to the " "LBaaS v1 load balancers. LBaaS v2 allows you to configure multiple listener " "ports on a single load balancer IP address." msgstr "" #: ../adv-config-lbaas.rst:16 msgid "" "Another LBaaS v2 implementation, `Octavia`_, has a separate API and separate " "worker processes that build load balancers within virtual machines on " "hypervisors that are managed by the Compute service. You do not need an " "agent for Octavia." msgstr "" #: ../adv-config-lbaas.rst:21 msgid "" "Currently, no migration path exists between v1 and v2 load balancers. If you " "choose to switch from v1 to v2, you must recreate all load balancers, pools, " "and health monitors." msgstr "" #: ../adv-config-lbaas.rst:28 msgid "LBaaS v1" msgstr "" #: ../adv-config-lbaas.rst:30 msgid "" "LBaaS v1 is deprecated in the Liberty release. These links provide more " "details about how LBaaS v1 works and how to configure it:" msgstr "" #: ../adv-config-lbaas.rst:33 msgid "`Load-Balancer-as-a-Service (LBaaS) overview`_" msgstr "" #: ../adv-config-lbaas.rst:34 msgid "`Basic Load-Balancer-as-a-Service operations`_" msgstr "" #: ../adv-config-lbaas.rst:40 msgid "LBaaS v2" msgstr "" #: ../adv-config-lbaas.rst:42 msgid "LBaaS v2 has several new concepts to understand:" msgstr "" #: ../adv-config-lbaas.rst:48 msgid "" "The load balancer occupies a neutron network port and has an IP address " "assigned from a subnet." msgstr "" #: ../adv-config-lbaas.rst:49 msgid "Load balancer" msgstr "" #: ../adv-config-lbaas.rst:52 msgid "" "Load balancers can listen for requests on multiple ports. Each one of those " "ports is specified by a listener." msgstr "" #: ../adv-config-lbaas.rst:53 msgid "Listener" msgstr "" #: ../adv-config-lbaas.rst:56 msgid "" "A pool holds a list of members that serve content through the load balancer." msgstr "" #: ../adv-config-lbaas.rst:56 msgid "Pool" msgstr "" #: ../adv-config-lbaas.rst:59 msgid "" "Members are servers that serve traffic behind a load balancer. Each member " "is specified by the IP address and port that it uses to serve traffic." msgstr "" #: ../adv-config-lbaas.rst:60 msgid "Member" msgstr "" #: ../adv-config-lbaas.rst:63 msgid "" "Members may go offline from time to time and health monitors divert traffic " "away from members that are not responding properly. Health monitors are " "associated with pools." msgstr "" #: ../adv-config-lbaas.rst:65 msgid "Health monitor" msgstr "" #: ../adv-config-lbaas.rst:67 msgid "" "LBaaS v2 has multiple implementations via different service plug-ins. The " "two most common implementations use either an agent or the Octavia services. " "Both implementations use the `LBaaS v2 API`_." msgstr "" #: ../adv-config-lbaas.rst:74 msgid "Configuring LBaaS v2 with an agent" msgstr "" #: ../adv-config-lbaas.rst:76 ../adv-config-lbaas.rst:130 msgid "" "Add the LBaaS v2 service plug-in to the ``service_plugins`` configuration " "directive in ``/etc/neutron/neutron.conf``. The plug-in list is comma-" "separated:" msgstr "" #: ../adv-config-lbaas.rst:84 msgid "" "Add the LBaaS v2 service provider to the ``service_provider`` configuration " "directive within the ``[service_providers]`` section in ``/etc/neutron/" "neutron.conf``:" msgstr "" #: ../adv-config-lbaas.rst:92 msgid "" "If you have existing service providers for other networking service plug-" "ins, such as VPNaaS or FWaaS, add the ``service_provider`` line shown above " "in the ``[service_providers]`` section as a separate line. These " "configuration directives are repeatable and are not comma-separated." msgstr "" #: ../adv-config-lbaas.rst:97 msgid "Run the ``neutron-lbaas`` database migration:" msgstr "" #: ../adv-config-lbaas.rst:103 msgid "" "If you have deployed LBaaS v1, **stop the LBaaS v1 agent now**. The v1 and " "v2 agents **cannot** run simultaneously." msgstr "" #: ../adv-config-lbaas.rst:106 msgid "Start the LBaaS v2 agent:" msgstr "" #: ../adv-config-lbaas.rst:114 msgid "" "Restart the Network service to activate the new configuration. You are now " "ready to create load balancers with the LBaaS v2 agent." msgstr "" #: ../adv-config-lbaas.rst:118 msgid "Configuring LBaaS v2 with Octavia" msgstr "" #: ../adv-config-lbaas.rst:120 msgid "" "Octavia provides additional capabilities for load balancers, including using " "a compute driver to build instances that operate as load balancers. The " "`Hands on Lab - Install and Configure OpenStack Octavia`_ session at the " "OpenStack Summit in Tokyo provides an overview of Octavia." msgstr "" #: ../adv-config-lbaas.rst:125 msgid "" "The DevStack documentation offers a `simple method to deploy Octavia`_ and " "test the service with redundant load balancer instances. If you already have " "Octavia installed and configured within your environment, you can configure " "the Network service to use Octavia:" msgstr "" #: ../adv-config-lbaas.rst:138 msgid "" "Add the Octavia service provider to the ``service_provider`` configuration " "directive within the ``[service_providers]`` section in ``/etc/neutron/" "neutron.conf``:" msgstr "" #: ../adv-config-lbaas.rst:146 msgid "" "Ensure that the LBaaS v1 and v2 service providers are removed from the " "``[service_providers]`` section. They are not used with Octavia. **Verify " "that all LBaaS agents are stopped.**" msgstr "" #: ../adv-config-lbaas.rst:150 msgid "" "Restart the Network service to activate the new configuration. You are now " "ready to create and manage load balancers with Octavia." msgstr "" #: ../adv-config-lbaas.rst:157 msgid "LBaaS v2 operations" msgstr "" #: ../adv-config-lbaas.rst:159 msgid "" "The same neutron commands are used for LBaaS v2 with an agent or with " "Octavia." msgstr "" #: ../adv-config-lbaas.rst:162 msgid "Building an LBaaS v2 load balancer" msgstr "" #: ../adv-config-lbaas.rst:164 msgid "" "Start by creating a load balancer on a network. In this example, the " "``private`` network is an isolated network with two web server instances:" msgstr "" #: ../adv-config-lbaas.rst:171 msgid "" "You can view the load balancer status and IP address with the ``lbaas-" "loadbalancer-show`` command:" msgstr "" #: ../adv-config-lbaas.rst:195 msgid "" "Update the security group to allow traffic to reach the new load balancer. " "Create a new security group along with ingress rules to allow traffic into " "the new load balancer. The neutron port for the load balancer is shown as " "``vip_port_id`` above." msgstr "" #: ../adv-config-lbaas.rst:200 msgid "" "Create a security group and rules to allow TCP port 80, TCP port 443, and " "all ICMP traffic:" msgstr "" #: ../adv-config-lbaas.rst:225 msgid "" "Apply the security group to the load balancer's network port using " "``vip_port_id`` from the :command:`lbaas-loadbalancer-show` command:" msgstr "" #: ../adv-config-lbaas.rst:234 msgid "" "This load balancer is active and ready to serve traffic on ``192.168.1.22``." msgstr "" #: ../adv-config-lbaas.rst:236 msgid "" "Verify that the load balancer is responding to pings before moving further:" msgstr "" #: ../adv-config-lbaas.rst:252 msgid "Adding an HTTP listener" msgstr "" #: ../adv-config-lbaas.rst:254 msgid "" "With the load balancer online, you can add a listener for plaintext HTTP " "traffic on port 80:" msgstr "" #: ../adv-config-lbaas.rst:265 msgid "" "You can begin building a pool and adding members to the pool to serve HTTP " "content on port 80. For this example, the web servers are ``192.168.1.16`` " "and ``192.168.1.17``:" msgstr "" #: ../adv-config-lbaas.rst:287 msgid "" "You can use ``curl`` to verify connectivity through the load balancers to " "your web servers:" msgstr "" #: ../adv-config-lbaas.rst:301 msgid "" "In this example, the load balancer uses the round robin algorithm and the " "traffic alternates between the web servers on the backend." msgstr "" #: ../adv-config-lbaas.rst:304 msgid "" "You can add a health monitor so that unresponsive servers are removed from " "the pool:" msgstr "" #: ../adv-config-lbaas.rst:316 msgid "" "In this example, the health monitor removes the server from the pool if it " "fails a health check at two five-second intervals. When the server recovers " "and begins responding to health checks again, it is added to the pool once " "again." msgstr "" #: ../adv-config-lbaas.rst:322 msgid "Adding an HTTPS listener" msgstr "" #: ../adv-config-lbaas.rst:324 msgid "" "You can add another listener on port 443 for HTTPS traffic. LBaaS v2 offers " "SSL/TLS termination at the load balancer, but this example takes a simpler " "approach and allows encrypted connections to terminate at each member server." msgstr "" #: ../adv-config-lbaas.rst:328 msgid "" "Start by creating a listener, attaching a pool, and then adding members:" msgstr "" #: ../adv-config-lbaas.rst:353 msgid "You can also add a health monitor for the HTTPS pool:" msgstr "" #: ../adv-config-lbaas.rst:364 msgid "The load balancer now handles traffic on ports 80 and 443." msgstr "" #: ../adv-config-lbaas.rst:367 msgid "Associating a floating IP address" msgstr "" #: ../adv-config-lbaas.rst:369 msgid "" "Load balancers that are deployed on a public or provider network that are " "accessible to external clients do not need a floating IP address assigned. " "External clients can directly access the virtual IP address (VIP) of those " "load balancers." msgstr "" #: ../adv-config-lbaas.rst:374 msgid "" "However, load balancers deployed onto private or isolated networks need a " "floating IP address assigned if they must be accessible to external clients. " "To complete this step, you must have a router between the private and public " "networks and an available floating IP address." msgstr "" #: ../adv-config-lbaas.rst:379 msgid "" "You can use the ``lbaas-loadbalancer-show`` command from the beginning of " "this section to locate the ``vip_port_id``. The ``vip_port_id`` is the ID of " "the network port that is assigned to the load balancer. You can associate a " "free floating IP address to the load balancer using ``floatingip-associate``:" msgstr "" #: ../adv-config-lbaas.rst:389 msgid "Setting quotas for LBaaS v2" msgstr "" #: ../adv-config-lbaas.rst:391 msgid "" "Quotas are available for limiting the number of load balancers and load " "balancer pools. By default, both quotas are set to 10." msgstr "" #: ../adv-config-lbaas.rst:394 msgid "You can adjust quotas using the :command:`quota-update` command:" msgstr "" #: ../adv-config-lbaas.rst:401 msgid "A setting of ``-1`` disables the quota for a tenant." msgstr "" #: ../adv-config-lbaas.rst:404 msgid "Retrieving load balancer statistics" msgstr "" #: ../adv-config-lbaas.rst:406 msgid "" "The LBaaS v2 agent collects four types of statistics for each load balancer " "every six seconds. Users can query these statistics with the :command:`lbaas-" "loadbalancer-stats` command:" msgstr "" #: ../adv-config-lbaas.rst:422 msgid "" "The ``active_connections`` count is the total number of connections that " "were active at the time the agent polled the load balancer. The other three " "statistics are cumulative since the load balancer was last started. For " "example, if the load balancer restarts due to a system error or a " "configuration change, these statistics will be reset." msgstr "" #: ../adv-config-network-rbac.rst:3 msgid "Role-Based Access Control for networks" msgstr "" #: ../adv-config-network-rbac.rst:5 msgid "" "A new policy framework was added during Liberty to enable both operators and " "users to grant specific projects access to resources. As of the Liberty " "release, the only access that can be granted via this feature is regular " "port creation permissions on networks." msgstr "" #: ../adv-config-network-rbac.rst:12 msgid "Sharing a network with specific projects" msgstr "" #: ../adv-config-network-rbac.rst:14 msgid "" "Sharing a network with a specific project is accomplished by creating a " "policy entry that permits the target project the ``access_as_shared`` action " "on that network." msgstr "" #: ../adv-config-network-rbac.rst:18 msgid "First, we create a network we want to share:" msgstr "" #: ../adv-config-network-rbac.rst:43 msgid "" "Now we create the policy entry using the :command:`rbac-create` command (In " "this example, the ID of the project we want to share with is " "``e28769db97d9449da658bc6931fcb683``):" msgstr "" #: ../adv-config-network-rbac.rst:64 msgid "" "The ``target-tenant`` parameter specifies the project that we wanted to gain " "access to the network. The ``action`` parameter specifies what we want the " "project to be allowed to do. The ``type`` parameter says that the target " "object is a network. The final parameter is the ID of the network we are " "granting access to." msgstr "" #: ../adv-config-network-rbac.rst:70 msgid "" "Project ``e28769db97d9449da658bc6931fcb683`` will now be able to see the " "network when running :command:`net-list` and :command:`net-show` and will " "also be able to create ports on that network. No other users (other than " "admins and the owner) will be able to see the network." msgstr "" #: ../adv-config-network-rbac.rst:75 msgid "" "To remove access for that project, just delete the policy that allows it " "using the :command:`rbac-delete` command:" msgstr "" #: ../adv-config-network-rbac.rst:83 msgid "" "If that project has ports on the network, the server will prevent the policy " "from being deleted until the ports have been deleted:" msgstr "" #: ../adv-config-network-rbac.rst:92 msgid "" "This process can be repeated any number of times to share a network with an " "arbitrary number of projects." msgstr "" #: ../adv-config-network-rbac.rst:96 msgid "How the 'shared' flag relates to these entries" msgstr "" #: ../adv-config-network-rbac.rst:98 msgid "" "As introduced in other guide entries, neutron provides a means of making a " "network available to every project. This is accomplished using the " "``shared`` flag on the network:" msgstr "" #: ../adv-config-network-rbac.rst:125 msgid "" "This is the equivalent of creating a policy on the network that permits " "every project to perform the action ``access_as_shared`` on that network. In " "fact, neutron treats them as the same thing, so we should be able to see a " "policy entry for that network using the :command:`rbac-list` command:" msgstr "" #: ../adv-config-network-rbac.rst:141 msgid "Then we can use the :command:`rbac-show` command to see the details:" msgstr "" #: ../adv-config-network-rbac.rst:158 msgid "" "Above we can see that the entry allows the action ``access_as_shared`` on " "object ``9a4af544-7158-456d-b180-95f2e11eaa8c`` of type ``network`` to " "target_tenant ``*``, which is a wildcard that represents all projects." msgstr "" #: ../adv-config-network-rbac.rst:162 msgid "" "As of Liberty, the ``shared`` flag is just a mapping to the underlying RBAC " "policies for a network. Setting the flag to ``True`` on a network creates a " "wildcard RBAC entry. Setting it to ``False`` removes the wildcard entry." msgstr "" #: ../adv-config-network-rbac.rst:167 msgid "" "When a :command:`net-list` or :command:`net-show` is done, the ``shared`` " "flag is calculated by the server based on the calling project and the RBAC " "entries for each network. If there is a wildcard entry, the ``shared`` flag " "is always set to ``True``. If there are only entries that share with " "specific projects, only the projects the network is shared to will see the " "flag as ``True`` and the rest will see the flag as ``False``." msgstr "" #: ../adv-config-network-rbac.rst:177 msgid "Preventing regular users from sharing networks with each other" msgstr "" #: ../adv-config-network-rbac.rst:179 msgid "" "The default ``policy.json`` shipped with neutron will not allow regular " "users to share networks with every other project using a wildcard; however, " "it will allow them to share networks with specific project IDs." msgstr "" #: ../adv-config-network-rbac.rst:184 msgid "" "If an operator wants to prevent normal users from doing this, the ``" "\"create_rbac_policy\":`` entry in ``policy.json`` can be adjusted from ``" "\"\"`` to ``\"rule:admin_only\"``." msgstr "" #: ../adv-config-network-rbac.rst:190 msgid "Limitations" msgstr "" #: ../adv-config-network-rbac.rst:192 msgid "" "A non-admin user that shares a network with another project using this " "feature will not be able to see or delete the ports created under the other " "project. This is because the neutron database operations automatically limit " "database queries to objects owned by the requesting user's project unless " "that user is an admin or a service user. This issue is being tracked by the " "following bug: https://bugs.launchpad.net/neutron/+bug/1498790" msgstr "" #: ../adv-config-operational.rst:3 msgid "Operational" msgstr "" #: ../adv-config-operational.rst:8 msgid "Logging" msgstr "" #: ../adv-config-operational.rst:10 msgid "" "http://docs.openstack.org/admin-guide-cloud/networking_adv-operational-" "features.html#logging-settings" msgstr "" #: ../adv-config-qos.rst:3 msgid "Using OpenStack Networking with QoS" msgstr "" #: ../adv-config-qos.rst:5 msgid "" "This page serves as a guide for how to use the \"Quality of Service\" (QoS) " "functionality of OpenStack Networking." msgstr "" #: ../adv-config-qos.rst:8 msgid "" "QoS is defined as the ability to guarantee certain network requirements like " "bandwidth, latency, jitter, and reliability in order to satisfy a Service " "Level Agreement (SLA) between an application provider and end users." msgstr "" #: ../adv-config-qos.rst:13 msgid "" "Network devices such as switches and routers can mark traffic so that it is " "handled with a higher priority to fulfill the QoS conditions agreed under " "the SLA. In other cases, certain network traffic such as Voice over IP " "(VoIP) and video streaming needs to be transmitted with minimal bandwidth " "constraints. On a system without network QoS management, all traffic will be " "transmitted in a \"best-effort\" manner making it impossible to guarantee " "service delivery to customers." msgstr "" #: ../adv-config-qos.rst:25 msgid "" "QoS is an advanced service plug-in. QoS is decoupled from the rest of the " "Neutron code on multiple levels and it is available through the ml2 " "extension driver." msgstr "" #: ../adv-config-qos.rst:29 msgid "" "Details about the DB models, API extension, and use cases are out of the " "scope of this guide but can be found in the `Neutron QoS specification " "`_." msgstr "" #: ../adv-config-qos.rst:35 msgid "Supported QoS rule types" msgstr "" #: ../adv-config-qos.rst:37 msgid "" "Any plug-in or ml2 mechanism driver can claim support for some QoS rule " "types by providing a plug-in/driver class property called " "'supported_qos_rule_types' that returns a list of strings that correspond to " "`QoS rule types `_." msgstr "" #: ../adv-config-qos.rst:43 msgid "" "For the Liberty release only egress bandwidth limit rules are supported." msgstr "" #: ../adv-config-qos.rst:45 msgid "" "In the most simple case, the property can be represented by a simple Python " "list defined on the class." msgstr "" #: ../adv-config-qos.rst:48 msgid "" "For an ml2 plug-in, the list of supported QoS rule types is defined as a " "common subset of rules supported by all active mechanism drivers." msgstr "" #: ../adv-config-qos.rst:52 msgid "" "The list of supported rule types reported by core plug-in is not enforced " "when accessing QoS rule resources. This is mostly because then we would not " "be able to create any rules while at least one ml2 driver lacks support for " "QoS (at the moment of writing, linuxbridge is such a driver)." msgstr "" # #-#-#-#-# adv-config-qos.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# config.pot (Networking Guide 0.9) #-#-#-#-# #: ../adv-config-qos.rst:60 ../config.rst:3 msgid "Configuration" msgstr "" #: ../adv-config-qos.rst:62 msgid "To enable the service, follow the steps below:" msgstr "" #: ../adv-config-qos.rst:64 msgid "On server side:" msgstr "" #: ../adv-config-qos.rst:66 msgid "Enable ``qos`` service in ``service_plugins``." msgstr "" #: ../adv-config-qos.rst:67 msgid "" "Set the needed notification_drivers in [qos] section (message_queue is the " "default)." msgstr "" #: ../adv-config-qos.rst:69 msgid "For ml2, add 'qos' to extension_drivers in [ml2] section." msgstr "" #: ../adv-config-qos.rst:71 msgid "On agent side (OVS):" msgstr "" #: ../adv-config-qos.rst:73 msgid "Add 'qos' to extensions in [agent] section." msgstr "" #: ../adv-config-qos.rst:76 msgid "" "QoS currently works with ml2 only (SR-IOV and Open vSwitch are the only " "drivers that are enabled for QoS in Liberty release)." msgstr "" #: ../adv-config-qos.rst:80 msgid "Trusted tenants policy.json configuration" msgstr "" #: ../adv-config-qos.rst:82 msgid "" "If tenants are trusted to administrate their own QoS policies in your cloud, " "neutron's file :file:`policy.json` can be modified to allow this." msgstr "" #: ../adv-config-qos.rst:85 msgid "Modify ``/etc/neutron/policy.json`` policy entries as follows::" msgstr "" #: ../adv-config-qos.rst:101 msgid "" "QoS policies are only created by admins with the default ``policy.json``. " "Therefore, you should have the Cloud Operator to set up them on behalf of " "the Cloud tenants." msgstr "" #: ../adv-config-qos.rst:105 msgid "" "If tenants are trusted to create their own policies, check the trusted " "tenants ``policy.json`` configuration section." msgstr "" #: ../adv-config-qos.rst:108 msgid "First, create a QoS policy and its bandwidth limit rules:" msgstr "" #: ../adv-config-qos.rst:137 msgid "" "Second, associate the created policy with an existing neutron port. In order " "to do this, user extracts the port id to be associated to the already " "created policy. In the next example, we will assign the ``bw-limiter`` " "policy to the VM with IP address 10.0.0.3" msgstr "" #: ../adv-config-qos.rst:156 msgid "" "In order to detach a port from the QoS policy, simply update again the port " "configuration." msgstr "" #: ../adv-config-qos.rst:165 msgid "Ports can be created with a policy attached to them too." msgstr "" #: ../adv-config-qos.rst:195 msgid "" "You can attach networks to a QoS policy. The meaning of this is that any " "compute port connected to the network will use the network policy by default " "unless the port has a specific policy attached to it. Network owned ports " "like dhcp and router ports are excluded from network policy application." msgstr "" #: ../adv-config-qos.rst:200 msgid "" "In order to attach a QoS policy to a network, update an existing network, or " "initially create the network attached to the policy." msgstr "" #: ../adv-config-qos.rst:210 msgid "Administrator enforcement" msgstr "" #: ../adv-config-qos.rst:212 msgid "" "Administrators are able to enforce policies on tenant ports or networks. As " "long as the policy is not shared, the tenant is not be able to detach any " "policy attached to a network or port." msgstr "" #: ../adv-config-qos.rst:216 msgid "" "If the policy is shared, the tenant is able to attach or detach such policy " "from its own ports and networks." msgstr "" #: ../adv-config-qos.rst:221 msgid "Rule modification" msgstr "" #: ../adv-config-qos.rst:222 msgid "" "You can modify rules at runtime. Rule modifications will be propagated to " "any attached port." msgstr "" #: ../adv-config-service-chaining.rst:3 msgid "Service chaining" msgstr "" #: ../adv-config-sriov.rst:3 msgid "Using SR-IOV functionality" msgstr "" #: ../adv-config-sriov.rst:5 msgid "" "The purpose of this page is to describe how to enable SR-IOV functionality " "available in OpenStack (using OpenStack Networking) as of the Juno release. " "This page serves as a how-to guide on configuring OpenStack Networking and " "OpenStack Compute to create neutron SR-IOV ports." msgstr "" #: ../adv-config-sriov.rst:13 msgid "" "PCI-SIG Single Root I/O Virtualization and Sharing (SR-IOV) specification " "defines a standardized mechanism to virtualize PCIe devices. The mechanism " "can virtualize a single PCIe Ethernet controller to appear as multiple PCIe " "devices. You can directly assign each virtual PCIe device to a VM, bypassing " "the hypervisor and virtual switch layer. As a result, users are able to " "achieve low latency and near-line wire speed." msgstr "" #: ../adv-config-sriov.rst:21 msgid "SR-IOV with ethernet" msgstr "" #: ../adv-config-sriov.rst:23 msgid "The following terms are used over the document:" msgstr "" #: ../adv-config-sriov.rst:29 msgid "Term" msgstr "" #: ../adv-config-sriov.rst:30 msgid "Definition" msgstr "" #: ../adv-config-sriov.rst:31 msgid "PF" msgstr "" #: ../adv-config-sriov.rst:32 msgid "" "Physical Function. This is the physical Ethernet controller that supports SR-" "IOV." msgstr "" #: ../adv-config-sriov.rst:34 msgid "VF" msgstr "" #: ../adv-config-sriov.rst:35 msgid "" "Virtual Function. This is a virtual PCIe device created from a physical " "Ethernet controller." msgstr "" #: ../adv-config-sriov.rst:39 msgid "In order to enable SR-IOV, the following steps are required:" msgstr "" #: ../adv-config-sriov.rst:41 ../adv-config-sriov.rst:95 msgid "Create Virtual Functions (Compute)" msgstr "" #: ../adv-config-sriov.rst:42 msgid "Whitelist PCI devices in nova-compute (Compute)" msgstr "" #: ../adv-config-sriov.rst:43 ../adv-config-sriov.rst:245 msgid "Configure neutron-server (Controller)" msgstr "" #: ../adv-config-sriov.rst:44 ../adv-config-sriov.rst:286 msgid "Configure nova-scheduler (Controller)" msgstr "" #: ../adv-config-sriov.rst:45 ../adv-config-sriov.rst:307 msgid "Enable neutron sriov-agent (Compute)" msgstr "" #: ../adv-config-sriov.rst:47 msgid "**Neutron sriov-agent**" msgstr "" #: ../adv-config-sriov.rst:49 msgid "There are 2 ways of configuring SR-IOV:" msgstr "" #: ../adv-config-sriov.rst:51 msgid "With the sriov-agent running on each compute node" msgstr "" #: ../adv-config-sriov.rst:52 msgid "Without the sriov-agent running on each compute node" msgstr "" #: ../adv-config-sriov.rst:54 msgid "" "The sriov-agent allows you to set the admin state of ports and starting from " "Liberty allows you to control port security (enable and disable " "spoofchecking) and QoS rate limit settings." msgstr "" #: ../adv-config-sriov.rst:60 msgid "" "With the sriov-agent mode is default in Liberty. Without the sriov-agent " "mode is deprecated in Liberty and removed in Mitaka." msgstr "" #: ../adv-config-sriov.rst:67 msgid "" "QoS is supported since Liberty, while it has limitations. max_burst_kbps " "(burst over max_kbps) is not supported. max_kbps is rounded to Mbps." msgstr "" #: ../adv-config-sriov.rst:70 msgid "" "Security Group is not supported. the agent is only working with " "``firewall_driver = neutron.agent.firewall.NoopFirewallDriver``." msgstr "" #: ../adv-config-sriov.rst:72 msgid "" "No OpenStack Dashboard integration. Users need to use CLI or API to create " "neutron SR-IOV ports." msgstr "" #: ../adv-config-sriov.rst:74 msgid "Live migration is not supported for instances with SR-IOV ports." msgstr "" #: ../adv-config-sriov.rst:77 msgid "" "ARP spoofing filtering is supported since Liberty when using sriov-agent." msgstr "" #: ../adv-config-sriov.rst:81 msgid "Environment example" msgstr "" #: ../adv-config-sriov.rst:82 msgid "" "We recommend using Open vSwitch with VLAN as segregation. This way you can " "combine normal VMs without SR-IOV ports and instances with SR-IOV ports on a " "single neutron network." msgstr "" #: ../adv-config-sriov.rst:88 msgid "" "Throughout this guide, eth3 is used as the PF and physnet2 is used as the " "provider network configured as a VLAN range. You are expected to change this " "according to your actual environment." msgstr "" #: ../adv-config-sriov.rst:96 msgid "" "In this step, create the VFs for the network interface that will be used for " "SR-IOV. Use eth3 as PF, which is also used as the interface for Open vSwitch " "VLAN and has access to the private networks of all machines." msgstr "" #: ../adv-config-sriov.rst:102 msgid "" "The step to create VFs differ between SR-IOV card Ethernet controller " "manufacturers. Currently the following manufacturers are known to work:" msgstr "" #: ../adv-config-sriov.rst:105 msgid "Intel" msgstr "" #: ../adv-config-sriov.rst:106 msgid "Mellanox" msgstr "" #: ../adv-config-sriov.rst:107 msgid "QLogic" msgstr "" #: ../adv-config-sriov.rst:109 msgid "" "For **Mellanox SR-IOV Ethernet cards** see: `Mellanox: HowTo Configure SR-" "IOV VFs `_" msgstr "" #: ../adv-config-sriov.rst:113 msgid "" "To create the VFs on Ubuntu for **Intel SR-IOV Ethernet cards**, do the " "following:" msgstr "" #: ../adv-config-sriov.rst:116 msgid "" "Make sure SR-IOV is enabled in BIOS, check for VT-d and make sure it is " "enabled. After enabling VT-d, enable IOMMU on Linux by adding " "``intel_iommu=on`` to kernel parameters. Edit the file :file:`/etc/default/" "grub`:" msgstr "" #: ../adv-config-sriov.rst:125 msgid "Run the following if you have added new parameters:" msgstr "" #: ../adv-config-sriov.rst:132 msgid "On each compute node, create the VFs via the PCI SYS interface:" msgstr "" #: ../adv-config-sriov.rst:140 msgid "" "On some PCI devices, observe that when changing the amount of VFs you " "receive the error ``Device or resource busy``. In this case, you first need " "to set ``sriov_numvfs`` to ``0``, then set it to your new value." msgstr "" #: ../adv-config-sriov.rst:146 msgid "" "Alternatively, you can create VFs by passing the ``max_vfs`` to the kernel " "module of your network interface. However, the ``max_vfs`` parameter has " "been deprecated, so the PCI SYS interface is the preferred method." msgstr "" #: ../adv-config-sriov.rst:151 msgid "You can determine the maximum number of VFs a PF can support:" msgstr "" #: ../adv-config-sriov.rst:158 msgid "" "If the interface is down, make sure it is set to ``up`` before launching a " "guest, else the instance will fail to spawn:" msgstr "" #: ../adv-config-sriov.rst:176 msgid "" "Now verify that the VFs have been created (Should see Virtual Function " "device):" msgstr "" #: ../adv-config-sriov.rst:183 msgid "Persist created VFs on reboot:" msgstr "" #: ../adv-config-sriov.rst:191 msgid "" "The suggested way of making PCI SYS settings persistent is through :file:" "`sysfs.conf` but for unknown reason changing :file:`sysfs.conf` does not " "have any effect on Ubuntu 14.04." msgstr "" #: ../adv-config-sriov.rst:195 msgid "" "For **QLogic SR-IOV Ethernet cards** see: `User's Guide OpenStack Deployment " "with SR-IOV Configuration `_" msgstr "" #: ../adv-config-sriov.rst:201 msgid "Whitelist PCI devices nova-compute (Compute)" msgstr "" #: ../adv-config-sriov.rst:203 msgid "" "Tell nova-compute which pci devices are allowed to be passed through. Edit " "the file :file:`/etc/nova/nova.conf`:" msgstr "" #: ../adv-config-sriov.rst:211 msgid "" "This tells nova that all VFs belonging to eth3 are allowed to be passed " "through to VMs and belong to the neutron provider network physnet2. Restart " "nova compute with :command:`service nova-compute restart` to let the changes " "have effect." msgstr "" #: ../adv-config-sriov.rst:216 msgid "" "Alternatively the ``pci_passthrough_whitelist`` parameter also supports " "whitelisting by:" msgstr "" #: ../adv-config-sriov.rst:219 msgid "" "PCI address: The address uses the same syntax as in ``lspci`` and an " "asterisk (*) can be used to match anything." msgstr "" #: ../adv-config-sriov.rst:229 msgid "" "PCI ``vendor_id`` and ``product_id`` as displayed by the Linux utility " "``lspci``." msgstr "" #: ../adv-config-sriov.rst:238 msgid "" "If the device defined by the PCI address or devname corresponds to a SR-IOV " "PF, all VFs under the PF will match the entry. Multiple " "pci_passthrough_whitelist entries per host are supported." msgstr "" #: ../adv-config-sriov.rst:247 msgid "" "Add ``sriovnicswitch`` as mechanism driver. Edit the file :file:`/etc/" "neutron/plugins/ml2/ml2_conf.ini`:" msgstr "" #: ../adv-config-sriov.rst:254 msgid "" "Find out the ``vendor_id`` and ``product_id`` of your **VFs** by logging in " "to your compute node with VFs previously created:" msgstr "" #: ../adv-config-sriov.rst:264 msgid "" "Update the :file:`/etc/neutron/plugins/ml2/ml2_conf_sriov.ini` on each " "controller. In our case the vendor_id is 8086 and the product_id is 10ed. " "Tell neutron the vendor_id and product_id of the VFs that are supported." msgstr "" #: ../adv-config-sriov.rst:273 msgid "" "Add the newly configured :file:`ml2_conf_sriov.ini` as parameter to the " "neutron-server daemon. Edit the file :file:`/etc/init/neutron-server.conf`:" msgstr "" #: ../adv-config-sriov.rst:282 msgid "" "To make the changes have effect, restart the neutron-server service with " "the :command:`service neutron-server restart`." msgstr "" #: ../adv-config-sriov.rst:288 msgid "" "On every controller node running nova-scheduler add PCIDeviceScheduler to " "the scheduler_default_filters parameter and add a new line for " "scheduler_available_filters parameter under the [default] section in :file:`/" "etc/nova/nova.conf`:" msgstr "" #: ../adv-config-sriov.rst:302 msgid "" "Now restart the nova-scheduler service with :command:`service nova-scheduler " "restart`." msgstr "" #: ../adv-config-sriov.rst:310 msgid "" "You only need to enable the sriov-agent if you decided to keep " "``agent_required=True`` in the step :ref:`configure_sriov_neutron_server`. " "If you set ``agent_required=False``, you can safely skip this step." msgstr "" #: ../adv-config-sriov.rst:314 msgid "" "On each compute node edit the file :file:`/etc/neutron/plugins/ml2/" "ml2_conf_sriov.ini`:" msgstr "" #: ../adv-config-sriov.rst:326 msgid "" "exclude_devices is empty so all the VFs associated with eth3 may be " "configured by the agent. If you want to exclude specific VFs, add them to " "the exclude_devices parameter as follows:" msgstr "" #: ../adv-config-sriov.rst:334 msgid "Test whether the sriov-agent runs successfully:" msgstr "" #: ../adv-config-sriov.rst:340 msgid "" "Enable the neutron-sriov-agent to start automatically at system start. If " "your distribution does not come with a daemon file for your init system, " "create a daemon configuration file. For example on Ubuntu install the " "package:" msgstr "" #: ../adv-config-sriov.rst:351 msgid "Creating instances with SR-IOV ports" msgstr "" #: ../adv-config-sriov.rst:352 msgid "" "After the configuration is done, you can now launch Instances with neutron " "SR-IOV ports." msgstr "" #: ../adv-config-sriov.rst:355 msgid "" "Get the id of the neutron network where you want the SR-IOV port to be " "created:" msgstr "" #: ../adv-config-sriov.rst:362 msgid "" "Create the SR-IOV port. We specify vnic_type direct, but other options " "include macvtap:" msgstr "" #: ../adv-config-sriov.rst:369 msgid "" "Create the VM. For the nic we specify the SR-IOV port created in step 2:" msgstr "" #: ../adv-config-sriov.rst:376 msgid "SR-IOV with InfiniBand" msgstr "" #: ../adv-config-sriov.rst:378 msgid "" "The support for SR-IOV with InfiniBand allows a Virtual PCI device (VF) to " "be directly mapped to the guest, allowing higher performance and advanced " "features such as RDMA (remote direct memory access). To use this feature, " "you must:" msgstr "" #: ../adv-config-sriov.rst:383 msgid "Use InfiniBand enabled network adapters." msgstr "" #: ../adv-config-sriov.rst:385 msgid "Run InfiniBand subnet managers to enable InfiniBand fabric." msgstr "" #: ../adv-config-sriov.rst:387 msgid "" "All InfiniBand networks must have a subnet manager running for the network " "to function. This is true even when doing a simple network of two machines " "with no switch and the cards are plugged in back-to-back. A subnet manager " "is required for the link on the cards to come up. It is possible to have " "more than one subnet manager. In this case, one of them will act as the " "master, and any other will act as a slave that will take over when the " "master subnet manager fails." msgstr "" #: ../adv-config-sriov.rst:395 msgid "Install the ``ebrctl`` utility on the compute nodes." msgstr "" #: ../adv-config-sriov.rst:397 msgid "" "Check that ``ebrctl`` is listed somewhere in ``/etc/nova/rootwrap.d/*``:" msgstr "" #: ../adv-config-sriov.rst:403 msgid "" "If ``ebrctl`` does not appear in any of the rootwrap files, add this to the " "``/etc/nova/rootwrap.d/compute.filters`` file in the ``[Filters]`` section." msgstr "" #: ../adv-config.rst:3 msgid "Advanced configuration" msgstr "" #: ../config-ml2-plug-in.rst:3 msgid "ML2 plug-in" msgstr "" #: ../config-ml2-plug-in.rst:6 msgid "Overview" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# config-server.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:9 ../config-server.rst:6 #: ../scenario-classic-lb.rst:145 ../scenario-classic-ovs.rst:159 #: ../scenario-dvr-ovs.rst:116 ../scenario-l3ha-lb.rst:123 #: ../scenario-l3ha-ovs.rst:132 ../scenario-provider-lb.rst:109 #: ../scenario-provider-ovs.rst:115 msgid "Architecture" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# config-server.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:12 ../config-server.rst:9 msgid "Configuration file organization, relationships, etc." msgstr "" #: ../config-ml2-plug-in.rst:15 msgid "Network type drivers" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-overview.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:17 ../intro-os-networking-overview.rst:68 msgid "Flat" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-overview.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:19 ../config-ml2-plug-in.rst:33 #: ../intro-os-networking-overview.rst:76 msgid "VLAN" msgstr "" #: ../config-ml2-plug-in.rst:21 ../config-ml2-plug-in.rst:37 msgid "GRE" msgstr "" #: ../config-ml2-plug-in.rst:23 ../config-ml2-plug-in.rst:41 msgid "VXLAN" msgstr "" #: ../config-ml2-plug-in.rst:26 msgid "Tenant network types" msgstr "" #: ../config-ml2-plug-in.rst:28 msgid "" "Similar info in: http://docs.openstack.org/admin-guide-cloud/networking_adv-" "features.html#provider-networks" msgstr "" #: ../config-ml2-plug-in.rst:31 msgid "Local" msgstr "" #: ../config-ml2-plug-in.rst:35 ../config-ml2-plug-in.rst:43 msgid "ID ranges" msgstr "" #: ../config-ml2-plug-in.rst:39 msgid "Tunnel ID ranges" msgstr "" #: ../config-ml2-plug-in.rst:45 msgid "Multicast discovery (L2 population)" msgstr "" #: ../config-ml2-plug-in.rst:48 msgid "Mechanism" msgstr "" #: ../config-ml2-plug-in.rst:50 msgid "Linux bridge" msgstr "" #: ../config-ml2-plug-in.rst:52 ../config-ml2-plug-in.rst:56 msgid "Option stanza/section" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:54 ../scenario-classic-ovs.rst:771 #: ../scenario-classic-ovs.rst:810 ../scenario-dvr-ovs.rst:621 #: ../scenario-dvr-ovs.rst:689 ../scenario-l3ha-ovs.rst:353 #: ../scenario-l3ha-ovs.rst:392 ../scenario-provider-ovs.rst:466 #: ../scenario-provider-ovs.rst:517 msgid "Open vSwitch" msgstr "" #: ../config-ml2-plug-in.rst:58 msgid "L2 population" msgstr "" #: ../config-ml2-plug-in.rst:60 msgid "Specialized" msgstr "" #: ../config-ml2-plug-in.rst:62 msgid "Open source" msgstr "" #: ../config-ml2-plug-in.rst:64 msgid "Explains that mechanisms such as OpenDaylight and OpenContrail exist" msgstr "" #: ../config-ml2-plug-in.rst:66 ../config-ml2-plug-in.rst:72 msgid "Does not cover how to do this" msgstr "" #: ../config-ml2-plug-in.rst:68 msgid "Proprietary (vendor)" msgstr "" #: ../config-ml2-plug-in.rst:70 msgid "Just specifies that these exist" msgstr "" #: ../config-ml2-plug-in.rst:75 msgid "Security" msgstr "" #: ../config-ml2-plug-in.rst:77 msgid "Options" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:80 ../intro-os-networking-service.rst:22 msgid "Agents" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:83 ../intro-os-networking-service.rst:47 msgid "L3" msgstr "" #: ../config-ml2-plug-in.rst:85 ../config-ml2-plug-in.rst:90 #: ../config-ml2-plug-in.rst:95 msgid "Configuration file" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-basic-networking.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:88 ../intro-basic-networking.rst:227 #: ../intro-os-networking-service.rst:51 msgid "DHCP" msgstr "" # #-#-#-#-# config-ml2-plug-in.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-ml2-plug-in.rst:93 ../intro-os-networking-service.rst:58 msgid "Metadata" msgstr "" # #-#-#-#-# config-server.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../config-server.rst:3 ../intro-os-networking-service.rst:6 #: ../scenario-classic-lb.rst:576 ../scenario-classic-ovs.rst:684 #: ../scenario-dvr-ovs.rst:531 ../scenario-l3ha-lb.rst:251 #: ../scenario-l3ha-ovs.rst:265 ../scenario-provider-lb.rst:439 #: ../scenario-provider-ovs.rst:486 msgid "Server" msgstr "" #: ../config-server.rst:12 msgid "Reference common configuration items" msgstr "" #: ../config.rst:5 msgid "" "This content currently under development. For general configuration, see the " "`Configuration Reference `_." msgstr "" #: ../deploy.rst:3 msgid "Deployment scenarios" msgstr "" #: ../index.rst:8 msgid "OpenStack Networking Guide" msgstr "" #: ../index.rst:11 msgid "Abstract" msgstr "" #: ../index.rst:13 msgid "" "This guide targets OpenStack administrators seeking to deploy and manage " "OpenStack Networking (neutron)." msgstr "" #: ../index.rst:16 msgid "This guide documents the OpenStack Liberty release." msgstr "" #: ../index.rst:19 msgid "Contents" msgstr "" #: ../index.rst:38 msgid "Search in this guide" msgstr "" #: ../index.rst:40 msgid ":ref:`search`" msgstr "" #: ../intro-basic-networking.rst:3 msgid "Basic networking" msgstr "" #: ../intro-basic-networking.rst:6 msgid "Ethernet" msgstr "" #: ../intro-basic-networking.rst:8 msgid "" "Ethernet is a networking protocol, specified by the IEEE 802.3 standard. " "Most wired network interface cards (NICs) communicate using Ethernet." msgstr "" #: ../intro-basic-networking.rst:11 msgid "" "In the `OSI model`_ of networking protocols, Ethernet occupies the second " "layer, which is known as the data link layer. When discussing Ethernet, you " "will often hear terms such as *local network*, *layer 2*, *L2*, *link layer* " "and *data link layer*." msgstr "" #: ../intro-basic-networking.rst:16 msgid "" "In an Ethernet network, the hosts connected to the network communicate by " "exchanging *frames*. Every host on an Ethernet network is uniquely " "identified by an address called the media access control (MAC) address. In " "particular, in an OpenStack environment, every virtual machine instance has " "a unique MAC address, which is different from the MAC address of the compute " "host. A MAC address has 48 bits and is typically represented as a " "hexadecimal string, such as ``08:00:27:b9:88:74``. The MAC address is hard-" "coded into the NIC by the manufacturer, although modern NICs allow you to " "change the MAC address programmatically. In Linux, you can retrieve the MAC " "address of a NIC using the ``ip`` command::" msgstr "" #: ../intro-basic-networking.rst:31 msgid "" "Conceptually, you can think of an Ethernet network as a single bus that each " "of the network hosts connects to. In early implementations, an Ethernet " "network consisted of a single coaxial cable that hosts would tap into to " "connect to the network. Modern Ethernet networks do not use this approach, " "and instead each network host connects directly to a network device called a " "*switch*. Still, this conceptual model is useful, and in network diagrams " "(including those generated by the OpenStack dashboard) an Ethernet network " "is often depicted as if it was a single bus. You'll sometimes hear an " "Ethernet network referred to as a *layer 2 segment*." msgstr "" #: ../intro-basic-networking.rst:42 msgid "" "In an Ethernet network, every host on the network can send a frame directly " "to every other host. An Ethernet network also supports broadcasts, so that " "one host can send a frame to every host on the network by sending to the " "special MAC address ``ff:ff:ff:ff:ff:ff``. ARP_ and DHCP_ are two notable " "protocols that use Ethernet broadcasts. Because Ethernet networks support " "broadcasts, you will sometimes hear an Ethernet network referred to as a " "*broadcast domain*." msgstr "" #: ../intro-basic-networking.rst:50 msgid "" "When a NIC receives an Ethernet frame, by default the NIC checks to see if " "the destination MAC address matches the address of the NIC (or the broadcast " "address), and the Ethernet frame is discarded if the MAC address does not " "match. For a compute host, this behavior is undesirable because the frame " "may be intended for one of the instances. NICs can be configured for " "*promiscuous mode*, where they pass all Ethernet frames to the operating " "system, even if the MAC address does not match. Compute hosts should always " "have the appropriate NICs configured for promiscuous mode." msgstr "" #: ../intro-basic-networking.rst:60 msgid "" "As mentioned earlier, modern Ethernet networks use switches to interconnect " "the network hosts. A switch is a box of networking hardware with a large " "number of ports, that forwards Ethernet frames from one connected host to " "another. When hosts first send frames over the switch, the switch doesn’t " "know which MAC address is associated with which port. If an Ethernet frame " "is destined for an unknown MAC address, the switch broadcasts the frame to " "all ports. The port learns which MAC addresses are at which ports by " "observing the traffic. Once it knows which MAC address is associated with a " "port, it can send Ethernet frames to the correct port instead of " "broadcasting. The switch maintains the mappings of MAC addresses to switch " "ports in a table called a *forwarding table* or *forwarding information " "base* (FIB). Switches can be daisy-chained together, and the resulting " "connection of switches and hosts behaves like a single network." msgstr "" #: ../intro-basic-networking.rst:78 msgid "VLANs" msgstr "" #: ../intro-basic-networking.rst:80 msgid "" "VLAN is a networking technology that enables a single switch to act as if it " "was multiple independent switches. Specifically, two hosts that are " "connected to the same switch but on different VLANs do not see each other's " "traffic. OpenStack is able to take advantage of VLANs to isolate the traffic " "of different tenants, even if the tenants happen to have instances running " "on the same compute host. Each VLAN has an associated numerical ID, between " "1 and 4095. We say \"VLAN 15\" to refer to the VLAN with numerical ID of 15." msgstr "" #: ../intro-basic-networking.rst:89 msgid "" "To understand how VLANs work, let's consider VLAN applications in a " "traditional IT environment, where physical hosts are attached to a physical " "switch, and no virtualization is involved. Imagine a scenario where you want " "three isolated networks, but you only have a single physical switch. The " "network administrator would choose three VLAN IDs, say, 10, 11, and 12, and " "would configure the switch to associate switchports with VLAN IDs. For " "example, switchport 2 might be associated with VLAN 10, switchport 3 might " "be associated with VLAN 11, and so forth. When a switchport is configured " "for a specific VLAN, it is called an *access port*. The switch is " "responsible for ensuring that the network traffic is isolated across the " "VLANs." msgstr "" #: ../intro-basic-networking.rst:101 msgid "" "Now consider the scenario that all of the switchports in the first switch " "become occupied, and so the organization buys a second switch and connects " "it to the first switch to expand the available number of switchports. The " "second switch is also configured to support VLAN IDs 10, 11, and 12. Now " "imagine host A connected to switch 1 on a port configured for VLAN ID 10 " "sends an Ethernet frame intended for host B connected to switch 2 on a port " "configured for VLAN ID 10. When switch 1 forwards the Ethernet frame to " "switch 2, it must communicate that the frame is associated with VLAN ID 10." msgstr "" #: ../intro-basic-networking.rst:111 msgid "" "If two switches are to be connected together, and the switches are " "configured for VLANs, then the switchports used for cross-connecting the " "switches must be configured to allow Ethernet frames from any VLAN to be " "forwarded to the other switch. In addition, the sending switch must tag each " "Ethernet frame with the VLAN ID so that the receiving switch can ensure that " "only hosts on the matching VLAN are eligible to receive the frame." msgstr "" #: ../intro-basic-networking.rst:118 msgid "" "When a switchport is configured to pass frames from all VLANs and tag them " "with the VLAN IDs it is called a *trunk port*. IEEE 802.1Q is the network " "standard that describes how VLAN tags are encoded in Ethernet frames when " "trunking is being used." msgstr "" #: ../intro-basic-networking.rst:123 msgid "" "Note that if you are using VLANs on your physical switches to implement " "tenant isolation in your OpenStack cloud, you must ensure that all of your " "switchports are configured as trunk ports." msgstr "" #: ../intro-basic-networking.rst:127 msgid "" "It is important that you select a VLAN range that your current network " "infrastructure is not using. For example, if you estimate that your cloud " "must support a maximum of 100 projects, pick a VLAN range outside of that " "value, such as VLAN 200–299. OpenStack and all physical network " "infrastructure that handles tenant networks must then support this VLAN " "range." msgstr "" #: ../intro-basic-networking.rst:133 msgid "" "Trunking is used to connect between different switches. Each trunk uses a " "tag to identify which VLAN is in use. This ensures that switches on the same " "VLAN can communicate." msgstr "" #: ../intro-basic-networking.rst:141 msgid "Subnets and ARP" msgstr "" #: ../intro-basic-networking.rst:143 msgid "" "While NICs use MAC addresses to address network hosts, TCP/IP applications " "use IP addresses. The Address Resolution Protocol (ARP) bridges the gap " "between Ethernet and IP by translating IP addresses into MAC addresses." msgstr "" #: ../intro-basic-networking.rst:147 msgid "" "IP addresses are broken up into two parts: a *network number* and a *host " "identifier*. Two hosts are on the same *subnet* if they have the same " "network number. Recall that two hosts can only communicate directly over " "Ethernet if they are on the same local network. ARP assumes that all " "machines that are in the same subnet are on the same local network. Network " "administrators must take care when assigning IP addresses and netmasks to " "hosts so that any two hosts that are in the same subnet are on the same " "local network, otherwise ARP does not work properly." msgstr "" #: ../intro-basic-networking.rst:156 msgid "" "To calculate the network number of an IP address, you must know the " "*netmask* associated with the address. A netmask indicates how many of the " "bits in the 32-bit IP address make up the network number." msgstr "" #: ../intro-basic-networking.rst:160 msgid "There are two syntaxes for expressing a netmask:" msgstr "" #: ../intro-basic-networking.rst:162 msgid "dotted quad" msgstr "" #: ../intro-basic-networking.rst:163 msgid "classless inter-domain routing (CIDR)" msgstr "" #: ../intro-basic-networking.rst:165 msgid "" "Consider an IP address of 192.168.1.5, where the first 24 bits of the " "address are the network number. In dotted quad notation, the netmask would " "be written as ``255.255.255.0``. CIDR notation includes both the IP address " "and netmask, and this example would be written as ``192.168.1.5/24``." msgstr "" #: ../intro-basic-networking.rst:172 msgid "" "Creating CIDR subnets including a multicast address or a loopback address " "cannot be used in an OpenStack environment. For example, creating a subnet " "using ``224.0.0.0/16`` or ``127.0.1.0/24`` is not supported." msgstr "" #: ../intro-basic-networking.rst:176 msgid "" "Sometimes we want to refer to a subnet, but not any particular IP address on " "the subnet. A common convention is to set the host identifier to all zeros " "to make reference to a subnet. For example, if a host's IP address is " "``10.10.53.24/16``, then we would say the subnet is ``10.10.0.0/16``." msgstr "" #: ../intro-basic-networking.rst:182 msgid "" "To understand how ARP translates IP addresses to MAC addresses, consider the " "following example. Assume host *A* has an IP address of ``192.168.1.5/24`` " "and a MAC address of ``fc:99:47:49:d4:a0``, and wants to send a packet to " "host *B* with an IP address of ``192.168.1.7``. Note that the network number " "is the same for both hosts, so host *A* is able to send frames directly to " "host *B*." msgstr "" #: ../intro-basic-networking.rst:189 msgid "" "The first time host *A* attempts to communicate with host *B*, the " "destination MAC address is not known. Host *A* makes an ARP request to the " "local network. The request is a broadcast with a message like this:" msgstr "" #: ../intro-basic-networking.rst:194 msgid "" "*To: everybody (ff:ff:ff:ff:ff:ff). I am looking for the computer who has IP " "address 192.168.1.7. Signed: MAC address fc:99:47:49:d4:a0*." msgstr "" #: ../intro-basic-networking.rst:197 msgid "Host *B* responds with a response like this:" msgstr "" #: ../intro-basic-networking.rst:199 msgid "" "*To: fc:99:47:49:d4:a0. I have IP address 192.168.1.7. Signed: MAC address " "54:78:1a:86:00:a5.*" msgstr "" #: ../intro-basic-networking.rst:202 msgid "Host *A* then sends Ethernet frames to host *B*." msgstr "" #: ../intro-basic-networking.rst:204 msgid "" "You can initiate an ARP request manually using the *arping* command. For " "example, to send an ARP request to IP address ``10.30.0.132``::" msgstr "" #: ../intro-basic-networking.rst:215 msgid "" "To reduce the number of ARP requests, operating systems maintain an ARP " "cache that contains the mappings of IP addresses to MAC address. On a Linux " "machine, you can view the contents of the ARP cache by using the *arp* " "command::" msgstr "" #: ../intro-basic-networking.rst:229 msgid "" "Hosts connected to a network use the Dynamic Host Configuration Protocol (:" "term:`DHCP`) to dynamically obtain IP addresses. A DHCP server hands out the " "IP addresses to network hosts, which are the DHCP clients." msgstr "" #: ../intro-basic-networking.rst:234 msgid "" "DHCP clients locate the DHCP server by sending a UDP_ packet from port 68 to " "address ``255.255.255.255`` on port 67. Address ``255.255.255.255`` is the " "local network broadcast address: all hosts on the local network see the UDP " "packets sent to this address. However, such packets are not forwarded to " "other networks. Consequently, the DHCP server must be on the same local " "network as the client, or the server will not receive the broadcast. The " "DHCP server responds by sending a UDP packet from port 67 to port 68 on the " "client. The exchange looks like this:" msgstr "" #: ../intro-basic-networking.rst:244 msgid "" "The client sends a discover (\"I’m a client at MAC address ``08:00:27:" "b9:88:74``, I need an IP address\")" msgstr "" #: ../intro-basic-networking.rst:246 msgid "" "The server sends an offer (\"OK ``08:00:27:b9:88:74``, I’m offering IP " "address ``10.10.0.112``\")" msgstr "" #: ../intro-basic-networking.rst:248 msgid "" "The client sends a request (\"Server ``10.10.0.131``, I would like to have " "IP ``10.10.0.112``\")" msgstr "" #: ../intro-basic-networking.rst:250 msgid "" "The server sends an acknowledgement (\"OK ``08:00:27:b9:88:74``, IP " "``10.10.0.112`` is yours\")" msgstr "" #: ../intro-basic-networking.rst:254 msgid "" "OpenStack uses a third-party program called dnsmasq_ to implement the DHCP " "server. Dnsmasq writes to the syslog, where you can observe the DHCP request " "and replies::" msgstr "" #: ../intro-basic-networking.rst:264 msgid "" "When troubleshooting an instance that is not reachable over the network, it " "can be helpful to examine this log to verify that all four steps of the DHCP " "protocol were carried out for the instance in question." msgstr "" #: ../intro-basic-networking.rst:273 msgid "IP" msgstr "" #: ../intro-basic-networking.rst:275 msgid "" "The Internet Protocol (IP) specifies how to route packets between hosts that " "are connected to different local networks. IP relies on special network " "hosts called *routers* or *gateways*. A router is a host that is connected " "to at least two local networks and can forward IP packets from one local " "network to another. A router has multiple IP addresses: one for each of the " "networks it is connected to." msgstr "" #: ../intro-basic-networking.rst:282 msgid "" "In the OSI model of networking protocols, IP occupies the third layer, which " "is known as the network layer. When discussing IP, you will often hear terms " "such as *layer 3*, *L3*, and *network layer*." msgstr "" #: ../intro-basic-networking.rst:286 msgid "" "A host sending a packet to an IP address consults its *routing table* to " "determine which machine on the local network(s) the packet should be sent " "to. The routing table maintains a list of the subnets associated with each " "local network that the host is directly connected to, as well as a list of " "routers that are on these local networks." msgstr "" #: ../intro-basic-networking.rst:292 msgid "" "On a Linux machine, any of the following commands displays the routing " "table::" msgstr "" #: ../intro-basic-networking.rst:298 msgid "Here is an example of output from ``ip route show``::" msgstr "" #: ../intro-basic-networking.rst:306 msgid "" "Line 1 of the output specifies the location of the default route, which is " "the effective routing rule if none of the other rules match. The router " "associated with the default route (``10.0.2.2`` in the example above) is " "sometimes referred to as the *default gateway*. A DHCP_ server typically " "transmits the IP address of the default gateway to the DHCP client along " "with the client's IP address and a netmask." msgstr "" #: ../intro-basic-networking.rst:313 msgid "" "Line 2 of the output specifies that IPs in the 10.0.2.0/24 subnet are on the " "local network associated with the network interface eth0." msgstr "" #: ../intro-basic-networking.rst:316 msgid "" "Line 3 of the output specifies that IPs in the 192.168.27.0/24 subnet are on " "the local network associated with the network interface eth1." msgstr "" #: ../intro-basic-networking.rst:319 msgid "" "Line 4 of the output specifies that IPs in the 192.168.122/24 subnet are on " "the local network associated with the network interface virbr0." msgstr "" #: ../intro-basic-networking.rst:322 msgid "" "The output of the ``route -n`` and ``netstat -rn`` commands are formatted in " "a slightly different way. This example shows how the same routes would be " "formatted using these commands::" msgstr "" #: ../intro-basic-networking.rst:334 msgid "" "The ``ip route get`` command outputs the route for a destination IP address. " "From the below example, destination IP address 10.0.2.14 is on the local " "network of eth0 and would be sent directly::" msgstr "" #: ../intro-basic-networking.rst:341 msgid "" "The destination IP address 93.184.216.34 is not on any of the connected " "local networks and would be forwarded to the default gateway at 10.0.2.2::" msgstr "" #: ../intro-basic-networking.rst:347 msgid "" "It is common for a packet to hop across multiple routers to reach its final " "destination. On a Linux machine, the ``traceroute`` and more recent ``mtr`` " "programs prints out the IP address of each router that an IP packet " "traverses along its path to its destination." msgstr "" #: ../intro-basic-networking.rst:355 msgid "TCP/UDP/ICMP" msgstr "" #: ../intro-basic-networking.rst:357 msgid "" "For networked software applications to communicate over an IP network, they " "must use a protocol layered atop IP. These protocols occupy the fourth layer " "of the OSI model known as the *transport layer* or *layer 4*. See the " "`Protocol Numbers`_ web page maintained by the Internet Assigned Numbers " "Authority (IANA) for a list of protocols that layer atop IP and their " "associated numbers." msgstr "" #: ../intro-basic-networking.rst:366 msgid "" "The *Transmission Control Protocol* (TCP) is the most commonly used layer 4 " "protocol in networked applications. TCP is a *connection-oriented* protocol: " "it uses a client-server model where a client connects to a server, where " "*server* refers to the application that receives connections. The typical " "interaction in a TCP-based application proceeds as follows:" msgstr "" #: ../intro-basic-networking.rst:374 msgid "Client connects to server." msgstr "" #: ../intro-basic-networking.rst:375 msgid "Client and server exchange data." msgstr "" #: ../intro-basic-networking.rst:376 msgid "Client or server disconnects." msgstr "" #: ../intro-basic-networking.rst:378 msgid "" "Because a network host may have multiple TCP-based applications running, TCP " "uses an addressing scheme called *ports* to uniquely identify TCP-based " "applications. A TCP port is associated with a number in the range 1-65535, " "and only one application on a host can be associated with a TCP port at a " "time, a restriction that is enforced by the operating system." msgstr "" #: ../intro-basic-networking.rst:384 msgid "" "A TCP server is said to *listen* on a port. For example, an SSH server " "typically listens on port 22. For a client to connect to a server using TCP, " "the client must know both the IP address of a server's host and the server's " "TCP port." msgstr "" #: ../intro-basic-networking.rst:389 msgid "" "The operating system of the TCP client application automatically assigns a " "port number to the client. The client owns this port number until the TCP " "connection is terminated, after which time the operating system reclaims the " "port number. These types of ports are referred to as *ephemeral ports*." msgstr "" #: ../intro-basic-networking.rst:395 msgid "" "IANA maintains a `registry of port numbers`_ for many TCP-based services, as " "well as services that use other layer 4 protocols that employ ports. " "Registering a TCP port number is not required, but registering a port number " "is helpful to avoid collisions with other services. See `Appendix B. " "Firewalls and default ports`_ of the `OpenStack Configuration Reference`_ " "for the default TCP ports used by various services involved in an OpenStack " "deployment." msgstr "" #: ../intro-basic-networking.rst:408 msgid "" "The most common application programming interface (API) for writing TCP-" "based applications is called *Berkeley sockets*, also known as *BSD sockets* " "or, simply, *sockets*. The sockets API exposes a *stream oriented* interface " "for writing TCP applications: from the perspective of a programmer, sending " "data over a TCP connection is similar to writing a stream of bytes to a " "file. It is the responsibility of the operating system's TCP/IP " "implementation to break up the stream of data into IP packets. The operating " "system is also responsible for automatically retransmitting dropped packets, " "and for handling flow control to ensure that transmitted data does not " "overrun the sender's data buffers, receiver's data buffers, and network " "capacity. Finally, the operating system is responsible for re-assembling the " "packets in the correct order into a stream of data on the receiver's side. " "Because TCP detects and retransmits lost packets, it is said to be a " "*reliable* protocol." msgstr "" #: ../intro-basic-networking.rst:423 msgid "" "The *User Datagram Protocol* (UDP) is another layer 4 protocol that is the " "basis of several well-known networking protocols. UDP is a *connectionless* " "protocol: two applications that communicate over UDP do not need to " "establish a connection before exchanging data. UDP is also an *unreliable* " "protocol. The operating system does not attempt to retransmit or even detect " "lost UDP packets. The operating system also does not provide any guarantee " "that the receiving application sees the UDP packets in the same order that " "they were sent in." msgstr "" #: ../intro-basic-networking.rst:432 msgid "" "UDP, like TCP, uses the notion of ports to distinguish between different " "applications running on the same system. Note, however, that operating " "systems treat UDP ports separately from TCP ports. For example, it is " "possible for one application to be associated with TCP port 16543 and a " "separate application to be associated with UDP port 16543." msgstr "" #: ../intro-basic-networking.rst:438 msgid "" "Like TCP, the sockets API is the most common API for writing UDP-based " "applications. The sockets API provides a *message-oriented* interface for " "writing UDP applications: a programmer sends data over UDP by transmitting a " "fixed-sized message. If an application requires retransmissions of lost " "packets or a well-defined ordering of received packets, the programmer is " "responsible for implementing this functionality in the application code." msgstr "" #: ../intro-basic-networking.rst:445 msgid "" "DHCP_, the Domain Name System (DNS), the Network Time Protocol (NTP), and :" "ref:`VXLAN` are examples of UDP-based protocols used in OpenStack " "deployments." msgstr "" #: ../intro-basic-networking.rst:448 msgid "" "UDP has support for one-to-many communication: sending a single packet to " "multiple hosts. An application can broadcast a UDP packet to all of the " "network hosts on a local network by setting the receiver IP address as the " "special IP broadcast address ``255.255.255.255``. An application can also " "send a UDP packet to a set of receivers using *IP multicast*. The intended " "receiver applications join a multicast group by binding a UDP socket to a " "special IP address that is one of the valid multicast group addresses. The " "receiving hosts do not have to be on the same local network as the sender, " "but the intervening routers must be configured to support IP multicast " "routing. VXLAN is an example of a UDP-based protocol that uses IP multicast." msgstr "" #: ../intro-basic-networking.rst:460 msgid "" "The *Internet Control Message Protocol* (ICMP) is a protocol used for " "sending control messages over an IP network. For example, a router that " "receives an IP packet may send an ICMP packet back to the source if there is " "no route in the router's routing table that corresponds to the destination " "address (ICMP code 1, destination host unreachable) or if the IP packet is " "too large for the router to handle (ICMP code 4, fragmentation required and " "\"don't fragment\" flag is set)." msgstr "" #: ../intro-basic-networking.rst:468 msgid "" "The *ping* and *mtr* Linux command-line tools are two examples of network " "utilities that use ICMP." msgstr "" #: ../intro-network-address-translation.rst:3 msgid "Network address translation" msgstr "" #: ../intro-network-address-translation.rst:5 msgid "" "*Network Address Translation* (NAT) is a process for modifying the source or " "destination addresses in the headers of an IP packet while the packet is in " "transit. In general, the sender and receiver applications are not aware that " "the IP packets are being manipulated." msgstr "" #: ../intro-network-address-translation.rst:10 msgid "" "NAT is often implemented by routers, and so we will refer to the host " "performing NAT as a *NAT router*. However, in OpenStack deployments it is " "typically Linux servers that implement the NAT functionality, not hardware " "routers. These servers use the iptables_ software package to implement the " "NAT functionality." msgstr "" #: ../intro-network-address-translation.rst:16 msgid "" "There are multiple variations of NAT, and here we describe three kinds " "commonly found in OpenStack deployments." msgstr "" #: ../intro-network-address-translation.rst:22 msgid "SNAT" msgstr "" #: ../intro-network-address-translation.rst:24 msgid "" "In *Source Network Address Translation* (SNAT), the NAT router modifies the " "IP address of the sender in IP packets. SNAT is commonly used to enable " "hosts with *private addresses* to communicate with servers on the public " "Internet." msgstr "" #: ../intro-network-address-translation.rst:29 msgid "`RFC 1918`_ reserves the following three subnets as private addresses:" msgstr "" #: ../intro-network-address-translation.rst:31 msgid "``10.0.0.0/8``" msgstr "" #: ../intro-network-address-translation.rst:32 msgid "``172.16.0.0/12``" msgstr "" #: ../intro-network-address-translation.rst:33 msgid "``192.168.0.0/16``" msgstr "" #: ../intro-network-address-translation.rst:37 msgid "" "These IP addresses are not publicly routable, meaning that a host on the " "public Internet can not send an IP packet to any of these addresses. Private " "IP addresses are widely used in both residential and corporate environments." msgstr "" #: ../intro-network-address-translation.rst:41 msgid "" "Often, an application running on a host with a private IP address will need " "to connect to a server on the public Internet. An example is a user who " "wants to access a public website such as www.openstack.org. If the IP " "packets reach the web server at www.openstack.org with a private IP address " "as the source, then the web server cannot send packets back to the sender." msgstr "" #: ../intro-network-address-translation.rst:47 msgid "" "SNAT solves this problem by modifying the source IP address to an IP address " "that is routable on the public Internet. There are different variations of " "SNAT; in the form that OpenStack deployments use, a NAT router on the path " "between the sender and receiver replaces the packet's source IP address with " "the router's public IP address. The router also modifies the source TCP or " "UDP port to another value, and the router maintains a record of the sender's " "true IP address and port, as well as the modified IP address and port." msgstr "" #: ../intro-network-address-translation.rst:56 msgid "" "When the router receives a packet with the matching IP address and port, it " "translates these back to the private IP address and port, and forwards the " "packet along." msgstr "" #: ../intro-network-address-translation.rst:60 msgid "" "Because the NAT router modifies ports as well as IP addresses, this form of " "SNAT is sometimes referred to as *Port Address Translation* (PAT). It is " "also sometimes referred to as *NAT overload*." msgstr "" #: ../intro-network-address-translation.rst:64 msgid "" "OpenStack uses SNAT to enable applications running inside of instances to " "connect out to the public Internet." msgstr "" #: ../intro-network-address-translation.rst:68 msgid "DNAT" msgstr "" #: ../intro-network-address-translation.rst:70 msgid "" "In *Destination Network Address Translation* (DNAT), the NAT router modifies " "the IP address of the destination in IP packet headers." msgstr "" #: ../intro-network-address-translation.rst:73 msgid "" "OpenStack uses DNAT to route packets from instances to the OpenStack " "metadata service. Applications running inside of instances access the " "OpenStack metadata service by making HTTP GET requests to a web server with " "IP address 169.254.169.254. In an OpenStack deployment, there is no host " "with this IP address. Instead, OpenStack uses DNAT to change the destination " "IP of these packets so they reach the network interface that a metadata " "service is listening on." msgstr "" #: ../intro-network-address-translation.rst:82 msgid "One-to-one NAT" msgstr "" #: ../intro-network-address-translation.rst:84 msgid "" "In *one-to-one NAT*, the NAT router maintains a one-to-one mapping between " "private IP addresses and public IP addresses. OpenStack uses one-to-one NAT " "to implement floating IP addresses." msgstr "" #: ../intro-network-namespaces.rst:3 msgid "Network namespaces" msgstr "" #: ../intro-network-namespaces.rst:5 msgid "" "A namespace is a way of scoping a particular set of identifiers. Using a " "namespace, you can use the same identifier multiple times in different " "namespaces. You can also restrict an identifier set visible to particular " "processes." msgstr "" #: ../intro-network-namespaces.rst:10 msgid "" "For example, Linux provides namespaces for networking and processes, among " "other things. If a process is running within a process namespace, it can " "only see and communicate with other processes in the same namespace. So, if " "a shell in a particular process namespace ran :command:`ps waux`, it would " "only show the other processes in the same namespace." msgstr "" #: ../intro-network-namespaces.rst:17 msgid "Linux network namespaces" msgstr "" #: ../intro-network-namespaces.rst:19 msgid "" "In a network namespace, the scoped 'identifiers' are network devices; so a " "given network device, such as ``eth0``, exists in a particular namespace. " "Linux starts up with a default network namespace, so if your operating " "system does not do anything special, that is where all the network devices " "will be located. But it is also possible to create further non-default " "namespaces, and create new devices in those namespaces, or to move an " "existing device from one namespace to another." msgstr "" #: ../intro-network-namespaces.rst:27 msgid "" "Each network namespace also has its own routing table, and in fact this is " "the main reason for namespaces to exist. A routing table is keyed by " "destination IP address, so network namespaces are what you need if you want " "the same destination IP address to mean different things at different times " "- which is something that OpenStack Networking requires for its feature of " "providing overlapping IP addresses in different virtual networks." msgstr "" #: ../intro-network-namespaces.rst:34 msgid "" "Each network namespace also has its own set of iptables (for both IPv4 and " "IPv6). So, you can apply different security to flows with the same IP " "addressing in different namespaces, as well as different routing." msgstr "" #: ../intro-network-namespaces.rst:38 msgid "" "Any given Linux process runs in a particular network namespace. By default " "this is inherited from its parent process, but a process with the right " "capabilities can switch itself into a different namespace; in practice this " "is mostly done using the :command:`ip netns exec NETNS COMMAND...` " "invocation, which starts ``COMMAND`` running in the namespace named " "``NETNS``. Suppose such a process sends out a message to IP address A.B.C.D, " "the effect of the namespace is that A.B.C.D will be looked up in that " "namespace's routing table, and that will determine the network device that " "the message is transmitted through." msgstr "" #: ../intro-network-namespaces.rst:48 msgid "Virtual routing and forwarding (VRF)" msgstr "" #: ../intro-network-namespaces.rst:50 msgid "" "Virtual routing and forwarding is an IP technology that allows multiple " "instances of a routing table to coexist on the same router at the same time. " "It is another name for the network namespace functionality described above." msgstr "" #: ../intro-networking-components.rst:3 msgid "Network components" msgstr "" #: ../intro-networking-components.rst:6 msgid "Switches" msgstr "" #: ../intro-networking-components.rst:8 msgid "" "Switches are Multi-Input Multi-Output devices that enable packets to travel " "from one node to another. Switches connect hosts that belong to the same " "layer-2 network. Switches enable forwarding of the packet received on one " "port (input) to another port (output) so that they reach the desired " "destination node. Switches operate at layer-2 in the networking model. They " "forward the traffic based on the destination Ethernet address in the packet " "header." msgstr "" # #-#-#-#-# intro-networking-components.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# intro-os-networking-overview.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../intro-networking-components.rst:17 #: ../intro-os-networking-overview.rst:122 ../scenario-classic-lb.rst:41 #: ../scenario-classic-ovs.rst:41 msgid "Routers" msgstr "" #: ../intro-networking-components.rst:19 msgid "" "Routers are special devices that enable packets to travel from one layer-3 " "network to another. Routers enable communication between two nodes on " "different layer-3 networks that are not directly connected to each other. " "Routers operate at layer-3 in the networking model. They route the traffic " "based on the destination IP address in the packet header." msgstr "" #: ../intro-networking-components.rst:26 msgid "Firewalls" msgstr "" #: ../intro-networking-components.rst:28 msgid "" "Firewalls are used to regulate traffic to and from a host or a network. A " "firewall can be either a specialized device connecting two networks or a " "software-based filtering mechanism implemented on an operating system. " "Firewalls are used to restrict traffic to a host based on the rules defined " "on the host. They can filter packets based on several criteria such as " "source IP address, destination IP address, port numbers, connection state, " "and so on. It is primarily used to protect the hosts from unauthorized " "access and malicious attacks. Linux-based operating systems implement " "firewalls through ``iptables``." msgstr "" #: ../intro-networking-components.rst:39 msgid "Load balancers" msgstr "" #: ../intro-networking-components.rst:41 msgid "" "Load balancers can be software-based or hardware-based devices that allow " "traffic to evenly be distributed across several servers. By distributing the " "traffic across multiple servers, it avoids overload of a single server " "thereby preventing a single point of failure in the product. This further " "improves the performance, network throughput, and response time of the " "servers. Load balancers are typically used in a 3-tier architecture. In this " "model, a load balancer receives a request from the front-end web server, " "which then forwards the request to one of the available back-end database " "servers for processing. The response from the database server is passed back " "to the web server for further processing." msgstr "" #: ../intro-networking.rst:3 msgid "Introduction to networking" msgstr "" #: ../intro-networking.rst:5 msgid "" "The OpenStack :term:`Networking` service provides an API that allows users " "to set up and define network connectivity and addressing in the cloud. The " "project code-name for Networking services is neutron. OpenStack Networking " "handles the creation and management of a virtual networking infrastructure, " "including networks, switches, subnets, and routers for devices managed by " "the OpenStack Compute service (nova). Advanced services such as firewalls " "or :term:`virtual private networks (VPNs) ` " "can also be used." msgstr "" #: ../intro-networking.rst:14 msgid "" "OpenStack Networking consists of the neutron-server, a database for " "persistent storage, and any number of plug-in agents, which provide other " "services such as interfacing with native Linux networking mechanisms, " "external devices, or SDN controllers." msgstr "" #: ../intro-networking.rst:19 msgid "" "OpenStack Networking is entirely standalone and can be deployed to a " "dedicated host. If your deployment uses a controller host to run centralized " "Compute components, you can deploy the Networking server to that specific " "host instead." msgstr "" #: ../intro-networking.rst:24 msgid "" "OpenStack Networking integrates with various other OpenStack components:" msgstr "" #: ../intro-networking.rst:27 msgid "" "OpenStack :term:`Identity` (keystone) is used for authentication and " "authorization of API requests." msgstr "" #: ../intro-networking.rst:30 msgid "" "OpenStack :term:`Compute` (nova) is used to plug each virtual NIC on the VM " "into a particular network." msgstr "" #: ../intro-networking.rst:33 msgid "" "OpenStack :term:`dashboard` (horizon) is used by administrators and tenant " "users to create and manage network services through a web-based graphical " "interface." msgstr "" #: ../intro-os-networking-overview.rst:3 msgid "Overview and components" msgstr "" #: ../intro-os-networking-overview.rst:5 msgid "" "OpenStack Networking allows you to create and manage network objects, such " "as networks, subnets, and ports, which other OpenStack services can use. " "Plug-ins can be implemented to accommodate different networking equipment " "and software, providing flexibility to OpenStack architecture and deployment." msgstr "" #: ../intro-os-networking-overview.rst:11 msgid "" "The Networking service, code-named neutron, provides an API that lets you " "define network connectivity and addressing in the cloud. The Networking " "service enables operators to leverage different networking technologies to " "power their cloud networking. The Networking service also provides an API to " "configure and manage a variety of network services ranging from L3 " "forwarding and :term:`NAT` to load balancing, perimeter firewalls, and " "virtual private networks." msgstr "" #: ../intro-os-networking-overview.rst:19 msgid "It includes the following components:" msgstr "" #: ../intro-os-networking-overview.rst:22 msgid "" "The OpenStack Networking API includes support for Layer 2 networking and :" "term:`IP address management (IPAM) `, as well " "as an extension for a Layer 3 router construct that enables routing between " "Layer 2 networks and gateways to external networks. OpenStack Networking " "includes a growing list of plug-ins that enable interoperability with " "various commercial and open source network technologies, including routers, " "switches, virtual switches and software-defined networking (SDN) controllers." msgstr "" #: ../intro-os-networking-overview.rst:29 msgid "API server" msgstr "" #: ../intro-os-networking-overview.rst:32 msgid "" "Plugs and unplugs ports, creates networks or subnets, and provides IP " "addressing. The chosen plug-in and agents differ depending on the vendor and " "technologies used in the particular cloud. It is important to mention that " "only one plug-in can be used at a time." msgstr "" #: ../intro-os-networking-overview.rst:35 msgid "OpenStack Networking plug-in and agents" msgstr "" #: ../intro-os-networking-overview.rst:38 msgid "" "Accepts and routes RPC requests between agents to complete API operations. " "Message queue is used in the ML2 plug-in for RPC between the neutron server " "and neutron agents that run on each hypervisor, in the ML2 mechanism drivers " "for :term:`Open vSwitch` and :term:`Linux bridge`." msgstr "" #: ../intro-os-networking-overview.rst:42 msgid "Messaging queue" msgstr "" #: ../intro-os-networking-overview.rst:45 msgid "OpenStack Networking concepts" msgstr "" #: ../intro-os-networking-overview.rst:47 msgid "" "To configure rich network topologies, you can create and configure networks " "and subnets and instruct other OpenStack services like Compute to attach " "virtual devices to ports on these networks. OpenStack Compute is a prominent " "consumer of OpenStack Networking to provide connectivity for its instances. " "In particular, OpenStack Networking supports each tenant having multiple " "private networks and enables tenants to choose their own IP addressing " "scheme, even if those IP addresses overlap with those that other tenants " "use. There are two types of network, tenant and provider networks. It is " "possible to share any of these types of networks among tenants as part of " "the network creation process." msgstr "" #: ../intro-os-networking-overview.rst:60 msgid "Tenant networks" msgstr "" #: ../intro-os-networking-overview.rst:62 msgid "" "Users create tenant networks for connectivity within projects. By default, " "they are fully isolated and are not shared with other projects. OpenStack " "Networking supports the following types of network isolation and overlay " "technologies." msgstr "" #: ../intro-os-networking-overview.rst:67 msgid "" "All instances reside on the same network, which can also be shared with the " "hosts. No VLAN tagging or other network segregation takes place." msgstr "" #: ../intro-os-networking-overview.rst:71 msgid "" "Networking allows users to create multiple provider or tenant networks using " "VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical " "network. This allows instances to communicate with each other across the " "environment. They can also communicate with dedicated servers, firewalls, " "load balancers, and other networking infrastructure on the same layer 2 VLAN." msgstr "" #: ../intro-os-networking-overview.rst:79 msgid "" "VXLAN and GRE are encapsulation protocols that create overlay networks to " "activate and control communication between compute instances. A Networking " "router is required to allow traffic to flow outside of the GRE or VXLAN " "tenant network. A router is also required to connect directly-connected " "tenant networks with external networks, including the Internet. The router " "provides the ability to connect to instances directly from an external " "network using floating IP addresses." msgstr "" #: ../intro-os-networking-overview.rst:85 msgid "GRE and VXLAN" msgstr "" #: ../intro-os-networking-overview.rst:88 msgid "Provider networks" msgstr "" #: ../intro-os-networking-overview.rst:90 msgid "" "The OpenStack administrator creates provider networks. These networks map to " "existing physical networks in the data center. Useful network types in this " "category are flat (untagged) and VLAN (802.1Q tagged)." msgstr "" #: ../intro-os-networking-overview.rst:97 msgid "" "To configure rich network topologies, you can create and configure networks " "and subnets and other OpenStack services like Compute will request to be " "connected to these networks by requesting virtual ports. In particular, " "Networking supports each tenant having multiple private networks and enables " "tenants to choose their own IP addressing scheme, even if those IP addresses " "overlap with those that other tenants use." msgstr "" #: ../intro-os-networking-overview.rst:105 msgid "Subnets" msgstr "" #: ../intro-os-networking-overview.rst:107 msgid "" "A block of IP addresses and associated configuration state. This is also " "known as the native IPAM (IP Address Management) provided by the networking " "service for both tenant and provider networks. Subnets are used to allocate " "IP addresses when new ports are created on a network." msgstr "" #: ../intro-os-networking-overview.rst:114 msgid "Ports" msgstr "" #: ../intro-os-networking-overview.rst:116 msgid "" "A port is a connection point for attaching a single device, such as the NIC " "of a virtual server, to a virtual network. The port also describes the " "associated network configuration, such as the MAC and IP addresses to be " "used on that port." msgstr "" #: ../intro-os-networking-overview.rst:124 msgid "" "This is a logical component that forwards data packets between networks. It " "also provides L3 and NAT forwarding to provide external network access for " "VMs on tenant networks. Required by certain plug-ins only." msgstr "" #: ../intro-os-networking-overview.rst:130 msgid "Security groups" msgstr "" #: ../intro-os-networking-overview.rst:132 msgid "" "A security group acts as a virtual firewall for your compute instances to " "control inbound and outbound traffic. Security groups act at the port level, " "not the subnet level. Therefore, each port in a subnet could be assigned to " "a different set of security groups. If you don't specify a particular group " "at launch time, the instance is automatically assigned to the default " "security group for that network." msgstr "" #: ../intro-os-networking-overview.rst:139 msgid "" "Security groups and security group rules give administrators and tenants the " "ability to specify the type of traffic and direction (ingress/egress) that " "is allowed to pass through a port. A security group is a container for " "security group rules. When a port is created, it is associated with a " "security group. If a security group is not specified, the port is associated " "with a 'default' security group. By default, this group drops all ingress " "traffic and allows all egress. Rules can be added to this group in order to " "change the behavior." msgstr "" #: ../intro-os-networking-overview.rst:148 msgid "Extensions" msgstr "" #: ../intro-os-networking-overview.rst:150 msgid "" "The OpenStack Networking service is extensible. Extensions serve two " "purposes: they allow the introduction of new features in the API without " "requiring a version change and they allow the introduction of vendor " "specific niche functionality. Applications can programmatically list " "available extensions by performing a GET on the :code:`/extensions` URI. " "Note that this is a versioned request; that is, an extension available in " "one API version might not be available in another." msgstr "" #: ../intro-os-networking-service.rst:3 msgid "Service and component hierarchy" msgstr "" #: ../intro-os-networking-service.rst:9 ../intro-os-networking-service.rst:17 #: ../intro-os-networking-service.rst:25 ../intro-os-networking-service.rst:38 #: ../intro-os-networking-service.rst:42 ../intro-os-networking-service.rst:49 #: ../intro-os-networking-service.rst:53 ../intro-os-networking-service.rst:60 msgid "Overview and concepts" msgstr "" #: ../intro-os-networking-service.rst:11 msgid "Provides API, manages database, etc." msgstr "" #: ../intro-os-networking-service.rst:14 msgid "Plug-ins" msgstr "" #: ../intro-os-networking-service.rst:19 msgid "Manages agents" msgstr "" #: ../intro-os-networking-service.rst:27 msgid "Provides layer 2/3 connectivity to instances" msgstr "" #: ../intro-os-networking-service.rst:29 msgid "Handles physical-virtual network transition" msgstr "" #: ../intro-os-networking-service.rst:31 msgid "Handles metadata, etc." msgstr "" #: ../intro-os-networking-service.rst:34 msgid "Layer 2 (Ethernet and Switching)" msgstr "" #: ../intro-os-networking-service.rst:36 msgid "Linux Bridge" msgstr "" #: ../intro-os-networking-service.rst:40 msgid "OVS" msgstr "" #: ../intro-os-networking-service.rst:45 msgid "Layer 3 (IP and Routing)" msgstr "" # #-#-#-#-# intro-os-networking-service.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# miscellaneous.pot (Networking Guide 0.9) #-#-#-#-# #: ../intro-os-networking-service.rst:56 ../miscellaneous.rst:3 msgid "Miscellaneous" msgstr "" #: ../intro-os-networking-service.rst:63 msgid "Services" msgstr "" #: ../intro-os-networking-service.rst:66 msgid "Routing services" msgstr "" #: ../intro-os-networking-service.rst:71 msgid "" "The Virtual Private Network-as-a-Service (VPNaaS) is a neutron extension " "that introduces the VPN feature set." msgstr "" #: ../intro-os-networking-service.rst:75 msgid "LbaaS" msgstr "" #: ../intro-os-networking-service.rst:77 msgid "" "The Load-Balancer-as-a-Service (LBaaS) API provisions and configures load " "balancers. The reference implementation is based on the HAProxy software " "load balancer." msgstr "" #: ../intro-os-networking-service.rst:82 msgid "FwaaS" msgstr "" #: ../intro-os-networking-service.rst:84 msgid "" "The Firewall-as-a-Service (FWaaS) API is an experimental API that enables " "early adopters and vendors to test their networking implementations." msgstr "" #: ../intro-os-networking.rst:3 msgid "Introduction to OpenStack Networking (neutron)" msgstr "" #: ../intro-tunnel-technologies.rst:3 msgid "Tunnel technologies" msgstr "" #: ../intro-tunnel-technologies.rst:5 msgid "" "Tunneling allows one network protocol to encapsulate another payload " "protocol such that packets from the payload protocol are passed as data on " "the delivery protocol. For example, this can be used to pass data securely " "over an untrusted network." msgstr "" #: ../intro-tunnel-technologies.rst:11 msgid "Generic routing encapsulation (GRE)" msgstr "" #: ../intro-tunnel-technologies.rst:13 msgid "" "GRE carries IP packets with private IP addresses over the Internet using " "delivery packets with public IP addresses." msgstr "" #: ../intro-tunnel-technologies.rst:19 msgid "Virtual extensible local area network (VXLAN)" msgstr "" #: ../intro-tunnel-technologies.rst:21 msgid "" "A VXLAN, virtual extensible local area network, allows the creation of a " "logical network for virtual machines across various networks. VXLAN " "encapsulates layer-2 Ethernet frames over layer-4 UDP packets." msgstr "" #: ../migration-classic-to-dvr.rst:3 msgid "Legacy to DVR" msgstr "" #: ../migration-classic-to-l3ha.rst:3 msgid "Legacy to L3 HA" msgstr "" #: ../migration-classic-to-l3ha.rst:5 msgid "" "This section describes the process of migrating from a classic router to an " "L3 HA router, which is available starting from the Mitaka release." msgstr "" #: ../migration-classic-to-l3ha.rst:8 msgid "" "Similar to the classic scenario, all network traffic on a project network " "that requires routing actively traverses only one network node regardless of " "the quantity of network nodes providing HA for the router. Therefore, this " "high-availability implementation primarily addresses failure situations " "instead of bandwidth constraints that limit performance. However, it " "supports random distribution of routers on different network nodes to reduce " "the chances of bandwidth constraints and to improve scaling." msgstr "" #: ../migration-classic-to-l3ha.rst:16 msgid "" "This section summarizes parts of :ref:`scenario-l3ha-ovs` and :ref:`scenario-" "l3ha-lb`. For details regarding needed infrastructure and configuration to " "allow actual L3 HA deployment, read the relevant guide before continuing " "with the migration process." msgstr "" # #-#-#-#-# migration-classic-to-l3ha.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# migration.pot (Networking Guide 0.9) #-#-#-#-# #: ../migration-classic-to-l3ha.rst:22 ../migration.rst:3 msgid "Migration" msgstr "" #: ../migration-classic-to-l3ha.rst:24 msgid "" "The migration process is quite simple, it involves turning down the router " "by setting the router's ``admin_state_up`` attribute to ``False``, upgrading " "the router to L3 HA and then setting the router's ``admin_state_up`` " "attribute back to ``True``." msgstr "" #: ../migration-classic-to-l3ha.rst:30 ../migration-classic-to-l3ha.rst:104 msgid "" "Once starting the migration, south-north connections (instances to internet) " "will be severed. New connections will be able to start only when the " "migration is complete." msgstr "" #: ../migration-classic-to-l3ha.rst:34 ../migration-classic-to-l3ha.rst:108 msgid "Here is the router we have used in our demonstration:" msgstr "" # #-#-#-#-# migration-classic-to-l3ha.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../migration-classic-to-l3ha.rst:53 ../migration-classic-to-l3ha.rst:127 #: ../scenario-classic-lb.rst:715 ../scenario-classic-lb.rst:737 #: ../scenario-classic-ovs.rst:816 ../scenario-classic-ovs.rst:838 #: ../scenario-dvr-ovs.rst:697 ../scenario-dvr-ovs.rst:723 #: ../scenario-dvr-ovs.rst:897 ../scenario-l3ha-lb.rst:390 #: ../scenario-l3ha-lb.rst:416 ../scenario-l3ha-lb.rst:579 #: ../scenario-l3ha-ovs.rst:398 ../scenario-l3ha-ovs.rst:424 #: ../scenario-l3ha-ovs.rst:587 ../scenario-provider-lb.rst:481 #: ../scenario-provider-lb.rst:502 ../scenario-provider-ovs.rst:542 #: ../scenario-provider-ovs.rst:563 msgid "Source the administrative project credentials." msgstr "" #: ../migration-classic-to-l3ha.rst:54 ../migration-classic-to-l3ha.rst:128 msgid "" "Set the admin_state_up to ``False``. This will severe south-north " "connections until admin_state_up is set to ``True`` again." msgstr "" #: ../migration-classic-to-l3ha.rst:62 ../migration-classic-to-l3ha.rst:136 msgid "Set the ``ha`` attribute of the router to ``True``." msgstr "" #: ../migration-classic-to-l3ha.rst:69 ../migration-classic-to-l3ha.rst:143 msgid "" "Set the admin_state_up to ``True``. After this, south-north connections can " "start." msgstr "" #: ../migration-classic-to-l3ha.rst:77 msgid "Make sure that the router's ``ha`` attribute has changed to ``True``." msgstr "" #: ../migration-classic-to-l3ha.rst:98 msgid "L3 HA to Legacy" msgstr "" #: ../migration-classic-to-l3ha.rst:100 msgid "" "To return to classic mode, you turn down the router again, turning off L3 HA " "and starting the router again" msgstr "" #: ../migration-classic-to-l3ha.rst:151 msgid "Make sure that the router's ``ha`` attribute has changed to ``False``." msgstr "" #: ../migration-nova-network-to-neutron.rst:3 msgid "Migrate legacy nova-network to OpenStack Networking (neutron)" msgstr "" #: ../migration-nova-network-to-neutron.rst:5 msgid "" "Two networking models exist in OpenStack. The first is called legacy " "networking (:term:`nova-network`) and it is a sub-process embedded in the " "Compute project (nova). This model has some limitations, such as creating " "complex network topologies, extending its back-end implementation to vendor-" "specific technologies, and providing tenant-specific networking elements. " "These limitations are the main reasons the OpenStack Networking (neutron) " "model was created." msgstr "" #: ../migration-nova-network-to-neutron.rst:13 msgid "" "This section describes the process of migrating clouds based on the legacy " "networking model to the OpenStack Networking model. This process requires " "additional changes to both compute and networking to support the migration. " "This document describes the overall process and the features required in " "both Networking and Compute." msgstr "" #: ../migration-nova-network-to-neutron.rst:19 msgid "" "The current process as designed is a minimally viable migration with the " "goal of deprecating and then removing legacy networking. Both the Compute " "and Networking teams agree that a \"one-button\" migration process from " "legacy networking to OpenStack Networking (neutron) is not an essential " "requirement for the deprecation and removal of the legacy networking at a " "future date. This section includes a process and tools which are designed to " "solve a simple use case migration." msgstr "" #: ../migration-nova-network-to-neutron.rst:27 msgid "" "Users are encouraged to take these tools, test them, provide feedback, and " "then expand on the feature set to suit their own deployments; deployers that " "refrain from participating in this process intending to wait for a path that " "better suits their use case are likely to be disappointed." msgstr "" #: ../migration-nova-network-to-neutron.rst:34 msgid "Impact and limitations" msgstr "" #: ../migration-nova-network-to-neutron.rst:36 msgid "" "The migration process from the legacy nova-network networking service to " "OpenStack Networking (neutron) has some limitations and impacts on the " "operational state of the cloud. It is critical to understand them in order " "to decide whether or not this process is acceptable for your cloud and all " "users." msgstr "" #: ../migration-nova-network-to-neutron.rst:43 msgid "Management impact" msgstr "" #: ../migration-nova-network-to-neutron.rst:45 msgid "" "The Networking REST API is publicly read-only until after the migration is " "complete. During the migration, Networking REST API is read-write only to " "nova-api, and changes to Networking are only allowed via nova-api." msgstr "" #: ../migration-nova-network-to-neutron.rst:50 msgid "" "The Compute REST API is available throughout the entire process, although " "there is a brief period where it is made read-only during a database " "migration. The Networking REST API will need to expose (to nova-api) all " "details necessary for reconstructing the information previously held in the " "legacy networking database." msgstr "" #: ../migration-nova-network-to-neutron.rst:56 msgid "" "Compute needs a per-hypervisor \"has_transitioned\" boolean change in the " "data model to be used during the migration process. This flag is no longer " "required once the process is complete." msgstr "" #: ../migration-nova-network-to-neutron.rst:61 msgid "Operations impact" msgstr "" #: ../migration-nova-network-to-neutron.rst:63 msgid "" "In order to support a wide range of deployment options, the migration " "process described here requires a rolling restart of hypervisors. The rate " "and timing of specific hypervisor restarts is under the control of the " "operator." msgstr "" #: ../migration-nova-network-to-neutron.rst:68 msgid "" "The migration may be paused, even for an extended period of time (for " "example, while testing or investigating issues) with some hypervisors on " "legacy networking and some on Networking, and Compute API remains fully " "functional. Individual hypervisors may be rolled back to legacy networking " "during this stage of the migration, although this requires an additional " "restart." msgstr "" #: ../migration-nova-network-to-neutron.rst:75 msgid "" "In order to support the widest range of deployer needs, the process " "described here is easy to automate but is not already automated. Deployers " "should expect to perform multiple manual steps or write some simple scripts " "in order to perform this migration." msgstr "" #: ../migration-nova-network-to-neutron.rst:81 msgid "Performance impact" msgstr "" #: ../migration-nova-network-to-neutron.rst:83 msgid "" "During the migration, nova-network API calls will go through an additional " "internal conversion to Networking calls. This will have different and likely " "poorer performance characteristics compared with either the pre-migration or " "post-migration APIs." msgstr "" #: ../migration-nova-network-to-neutron.rst:89 msgid "Migration process overview" msgstr "" #: ../migration-nova-network-to-neutron.rst:91 msgid "" "Start neutron-server in intended final config, except with REST API " "restricted to read-write only by nova-api." msgstr "" #: ../migration-nova-network-to-neutron.rst:93 msgid "Make the Compute REST API read-only." msgstr "" #: ../migration-nova-network-to-neutron.rst:94 msgid "" "Run a DB dump/restore tool that creates Networking data structures " "representing current legacy networking config." msgstr "" #: ../migration-nova-network-to-neutron.rst:96 msgid "" "Enable a nova-api proxy that recreates internal Compute objects from " "Networking information (via the Networking REST API)." msgstr "" #: ../migration-nova-network-to-neutron.rst:99 msgid "" "Make Compute REST API read-write again. This means legacy networking DB is " "now unused, new changes are now stored in the Networking DB, and no rollback " "is possible from here without losing those new changes." msgstr "" #: ../migration-nova-network-to-neutron.rst:105 msgid "" "At this moment the Networking DB is the source of truth, but nova-api is the " "only public read-write API." msgstr "" #: ../migration-nova-network-to-neutron.rst:108 msgid "" "Next, you'll need to migrate each hypervisor. To do that, follow these " "steps:" msgstr "" #: ../migration-nova-network-to-neutron.rst:110 msgid "" "Disable the hypervisor. This would be a good time to live migrate or " "evacuate the compute node, if supported." msgstr "" #: ../migration-nova-network-to-neutron.rst:112 msgid "Disable nova-compute." msgstr "" #: ../migration-nova-network-to-neutron.rst:113 msgid "Enable the Networking agent." msgstr "" #: ../migration-nova-network-to-neutron.rst:114 msgid "" "Set the \"has_transitioned\" flag in the Compute hypervisor database/config." msgstr "" #: ../migration-nova-network-to-neutron.rst:115 msgid "" "Reboot the hypervisor (or run \"smart\" live transition tool if available)." msgstr "" #: ../migration-nova-network-to-neutron.rst:116 msgid "Re-enable the hypervisor." msgstr "" #: ../migration-nova-network-to-neutron.rst:118 msgid "" "At this point, all compute nodes have been migrated, but they are still " "using the nova-api API and Compute gateways. Finally, enable OpenStack " "Networking by following these steps:" msgstr "" #: ../migration-nova-network-to-neutron.rst:122 msgid "" "Bring up the Networking (l3) nodes. The new routers will have identical MAC" "+IPs as old Compute gateways so some sort of immediate cutover is possible, " "except for stateful connections issues such as NAT." msgstr "" #: ../migration-nova-network-to-neutron.rst:126 msgid "Make the Networking API read-write and disable legacy networking." msgstr "" #: ../migration-nova-network-to-neutron.rst:128 msgid "Migration Completed!" msgstr "" #: ../misc-add-ha-for-dhcp.rst:3 msgid "Adding high availability for DHCP" msgstr "" #: ../misc-add-ha-for-dhcp.rst:5 msgid "FIXME (Simple note, needs to be added.)" msgstr "" #: ../misc-add-ha-for-dhcp.rst:8 msgid "DHCP agents" msgstr "" #: ../misc-add-ha-for-dhcp.rst:10 msgid "" "FIXME: Content needs to be written; see DHCP agents (http://docs.openstack." "org/admin-guide-cloud/networking_multi-dhcp-agents.html)" msgstr "" #: ../misc-libvirt.rst:3 msgid "Disabling libvirt networking" msgstr "" #: ../misc-libvirt.rst:5 msgid "" "Most OpenStack deployments use the libvirt_ toolkit for interacting with the " "hypervisor. Specifically, OpenStack Compute uses libvirt for tasks such as " "booting and terminating virtual machine instances. When OpenStack Compute " "boots a new instance, libvirt provides OpenStack with the VIF associated " "with the instance, and OpenStack Compute plugs the VIF into a virtual device " "provided by OpenStack Network. The libvirt toolkit itself does not provide " "any networking functionality in OpenStack deployments." msgstr "" #: ../misc-libvirt.rst:15 msgid "" "However, libvirt is capable of providing networking services to the virtual " "machines that it manages. In particular, libvirt can be configured to " "provide networking functionality akin to a simplified, single-node version " "of OpenStack. Users can use libvirt to create layer 2 networks that are " "similar to OpenStack Networking's networks, confined to a single node." msgstr "" #: ../misc-libvirt.rst:22 msgid "libvirt network implementation" msgstr "" #: ../misc-libvirt.rst:24 msgid "" "By default, libvirt's networking functionality is enabled, and libvirt " "creates a network when the system boots. To implement this network, libvirt " "leverages some of the same technologies that OpenStack Network does. In " "particular, libvirt uses:" msgstr "" #: ../misc-libvirt.rst:29 msgid "Linux bridging for implementing a layer 2 network" msgstr "" #: ../misc-libvirt.rst:30 msgid "dnsmasq for providing IP addresses to virtual machines using DHCP" msgstr "" #: ../misc-libvirt.rst:31 msgid "" "iptables to implement SNAT so instances can connect out to the public " "internet, and to ensure that virtual machines are permitted to communicate " "with dnsmasq using DHCP" msgstr "" #: ../misc-libvirt.rst:35 msgid "" "By default, libvirt creates a network named *default*. The details of this " "network may vary by distribution; on Ubuntu this network involves:" msgstr "" #: ../misc-libvirt.rst:38 msgid "" "a Linux bridge named ``virbr0`` with an IP address of ``192.168.122.1/24``" msgstr "" #: ../misc-libvirt.rst:39 msgid "" "a dnsmasq process that listens on the ``virbr0`` interface and hands out IP " "addresses in the range ``192.168.122.2-192.168.122.254``" msgstr "" #: ../misc-libvirt.rst:41 msgid "a set of iptables rules" msgstr "" #: ../misc-libvirt.rst:43 msgid "" "When libvirt boots a virtual machine, it places the machine's VIF in the " "bridge ``virbr0`` unless explicitly told not to." msgstr "" #: ../misc-libvirt.rst:46 msgid "" "On Ubuntu, the iptables ruleset that libvirt creates includes the following " "rules::" msgstr "" #: ../misc-libvirt.rst:69 msgid "" "The following shows the dnsmasq process that libvirt manages as it appears " "in the output of :command:`ps`::" msgstr "" #: ../misc-libvirt.rst:75 msgid "How to disable libvirt networks" msgstr "" #: ../misc-libvirt.rst:77 msgid "" "Although OpenStack does not make use of libvirt's networking, this " "networking will not interfere with OpenStack's behavior, and can be safely " "left enabled. However, libvirt's networking can be a nuisance when debugging " "OpenStack networking issues. Because libvirt creates an additional bridge, " "dnsmasq process, and iptables ruleset, these may distract an operator " "engaged in network troubleshooting. Unless you need to start up virtual " "machines using libvirt directly, you can safely disable libvirt's network." msgstr "" #: ../misc-libvirt.rst:86 msgid "To view the defined libvirt networks and their state::" msgstr "" #: ../misc-libvirt.rst:93 msgid "To deactivate the libvirt network named *default*::" msgstr "" #: ../misc-libvirt.rst:97 msgid "" "Deactivating the network will remove the ``virbr0`` bridge, terminate the " "dnsmasq process, and remove the iptables rules." msgstr "" #: ../misc-libvirt.rst:100 msgid "To prevent the network from automatically starting on boot::" msgstr "" #: ../misc-libvirt.rst:104 msgid "To activate the network after it has been deactivated::" msgstr "" #: ../scenario-classic-lb.rst:5 msgid "Scenario: Classic with Linux Bridge" msgstr "" #: ../scenario-classic-lb.rst:7 msgid "" "This scenario describes a classic implementation of the OpenStack Networking " "service using the ML2 plug-in with Linux bridge." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:10 ../scenario-classic-ovs.rst:10 msgid "" "The classic implementation contributes the networking portion of self-" "service virtual data center infrastructure by providing a method for regular " "(non-privileged) users to manage virtual networks within a project and " "includes the following components:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:15 ../scenario-classic-ovs.rst:15 msgid "Project (tenant) networks" msgstr "" #: ../scenario-classic-lb.rst:17 msgid "" "Project networks provide connectivity to instances for a particular project. " "Regular (non-privileged) users can manage project networks within the " "allocation that an administrator or operator defines for for them. Project " "networks can use VLAN or VXLAN transport methods depending on the " "allocation. Project networks generally use private IP address ranges " "(RFC1918) and lack connectivity to external networks such as the Internet. " "Networking refers to IP addresses on project networks as *fixed* IP " "addresses." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:26 ../scenario-classic-ovs.rst:26 msgid "External networks" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:28 ../scenario-classic-ovs.rst:28 msgid "" "External networks provide connectivity to external networks such as the " "Internet. Only administrative (privileged) users can manage external " "networks because they interface with the physical network infrastructure. " "External networks can use flat or VLAN transport methods depending on the " "physical network infrastructure and generally use public IP address ranges." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:36 ../scenario-classic-ovs.rst:36 msgid "" "A flat network essentially uses the untagged or native VLAN. Similar to " "layer-2 properties of physical networks, only one flat network can exist per " "external bridge. In most cases, production deployments should use VLAN " "transport for external networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:43 ../scenario-classic-ovs.rst:43 msgid "" "Routers typically connect project and external networks. By default, they " "implement SNAT to provide outbound external connectivity for instances on " "project networks. Each router uses an IP address in the external network " "allocation for SNAT. Routers also use DNAT to provide inbound external " "connectivity for instances on project networks. Networking refers to IP " "addresses on routers that provide inbound external connectivity for " "instances on project networks as *floating* IP addresses. Routers can also " "connect project networks that belong to the same project." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:52 ../scenario-classic-ovs.rst:52 msgid "Supporting services" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:54 ../scenario-classic-ovs.rst:54 msgid "" "Other supporting services include DHCP and metadata. The DHCP service " "manages IP addresses for instances on project networks. The metadata service " "provides an API for instances on project networks to obtain metadata such as " "SSH keys." msgstr "" #: ../scenario-classic-lb.rst:59 msgid "" "The example configuration creates one flat external network and one VXLAN " "project network. However, this configuration also supports VLAN external and " "project networks. The Linux bridge agent does not support GRE project " "networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:65 ../scenario-classic-ovs.rst:64 #: ../scenario-dvr-ovs.rst:25 ../scenario-l3ha-lb.rst:41 #: ../scenario-l3ha-ovs.rst:35 ../scenario-provider-lb.rst:50 #: ../scenario-provider-ovs.rst:43 msgid "Prerequisites" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:67 ../scenario-classic-ovs.rst:66 #: ../scenario-dvr-ovs.rst:27 msgid "" "These prerequisites define the minimal physical infrastructure and immediate " "OpenStack service dependencies necessary to deploy this scenario. For " "example, the Networking service immediately depends on the Identity service " "and the Compute service immediately depends on the Networking service. These " "dependencies lack services such as the Image service because the Networking " "service does not immediately depend on it. However, the Compute service " "depends on the Image service to launch an instance. The example " "configuration in this scenario assumes basic configuration knowledge of " "Networking service components." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:78 ../scenario-classic-ovs.rst:77 #: ../scenario-dvr-ovs.rst:38 ../scenario-l3ha-lb.rst:55 #: ../scenario-l3ha-ovs.rst:49 ../scenario-provider-lb.rst:65 #: ../scenario-provider-ovs.rst:58 msgid "Infrastructure" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:80 ../scenario-classic-ovs.rst:79 #: ../scenario-dvr-ovs.rst:40 ../scenario-l3ha-lb.rst:57 #: ../scenario-l3ha-ovs.rst:51 msgid "One controller node with one network interface: management." msgstr "" #: ../scenario-classic-lb.rst:81 msgid "" "One network node with four network interfaces: management, project tunnel " "networks, VLAN project networks, and external (typically the Internet)." msgstr "" #: ../scenario-classic-lb.rst:83 msgid "" "At least one compute nodes with three network interfaces: management, " "project tunnel networks, and VLAN project networks." msgstr "" #: ../scenario-classic-lb.rst:86 msgid "" "To improve understanding of network traffic flow, the network and compute " "nodes contain a separate network interface for VLAN project networks. In " "production environments, you can use any network interface for VLAN project " "networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:91 ../scenario-classic-ovs.rst:95 msgid "" "In the example configuration, the management network uses 10.0.0.0/24, the " "tunnel network uses 10.0.1.0/24, and the external network uses " "203.0.113.0/24. The VLAN network does not require an IP address range " "because it only handles layer-2 connectivity." msgstr "" #: ../scenario-classic-lb.rst:106 msgid "" "For VLAN external and project networks, the physical network infrastructure " "must support VLAN tagging. For best performance with VXLAN project networks, " "the network infrastructure should support jumbo frames." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:112 ../scenario-l3ha-lb.rst:90 msgid "Using VXLAN project networks requires kernel 3.13 or newer." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:115 ../scenario-classic-ovs.rst:128 #: ../scenario-dvr-ovs.rst:85 ../scenario-l3ha-lb.rst:93 #: ../scenario-l3ha-ovs.rst:100 ../scenario-provider-lb.rst:86 #: ../scenario-provider-ovs.rst:92 msgid "OpenStack services - controller node" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:117 ../scenario-classic-ovs.rst:130 #: ../scenario-dvr-ovs.rst:87 ../scenario-l3ha-lb.rst:95 #: ../scenario-l3ha-ovs.rst:102 ../scenario-provider-lb.rst:88 #: ../scenario-provider-ovs.rst:94 msgid "" "Operational SQL server with ``neutron`` database and appropriate " "configuration in the :file:`neutron.conf` file." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:119 ../scenario-classic-ovs.rst:132 #: ../scenario-dvr-ovs.rst:89 ../scenario-l3ha-lb.rst:97 #: ../scenario-l3ha-ovs.rst:104 ../scenario-provider-lb.rst:90 #: ../scenario-provider-ovs.rst:96 msgid "" "Operational message queue service with appropriate configuration in the :" "file:`neutron.conf` file." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:121 ../scenario-classic-lb.rst:138 #: ../scenario-classic-ovs.rst:134 ../scenario-classic-ovs.rst:144 #: ../scenario-classic-ovs.rst:152 ../scenario-dvr-ovs.rst:91 #: ../scenario-dvr-ovs.rst:108 ../scenario-l3ha-lb.rst:99 #: ../scenario-l3ha-lb.rst:116 ../scenario-l3ha-ovs.rst:106 #: ../scenario-l3ha-ovs.rst:124 ../scenario-provider-lb.rst:92 #: ../scenario-provider-lb.rst:102 ../scenario-provider-ovs.rst:98 #: ../scenario-provider-ovs.rst:108 msgid "" "Operational OpenStack Identity service with appropriate configuration in " "the :file:`neutron.conf` file." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:123 ../scenario-classic-ovs.rst:136 #: ../scenario-dvr-ovs.rst:93 ../scenario-l3ha-lb.rst:101 #: ../scenario-provider-lb.rst:94 ../scenario-provider-lb.rst:104 #: ../scenario-provider-ovs.rst:100 msgid "" "Operational OpenStack Compute controller/management service with appropriate " "configuration to use neutron in the :file:`nova.conf` file." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:125 ../scenario-classic-ovs.rst:139 #: ../scenario-dvr-ovs.rst:95 ../scenario-l3ha-lb.rst:103 #: ../scenario-l3ha-ovs.rst:111 msgid "Neutron server service, ML2 plug-in, and any dependencies." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:128 ../scenario-classic-ovs.rst:142 #: ../scenario-dvr-ovs.rst:98 msgid "OpenStack services - network node" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:130 ../scenario-dvr-ovs.rst:100 #: ../scenario-l3ha-lb.rst:108 ../scenario-l3ha-ovs.rst:116 msgid "" "Operational OpenStack Identity service with appropriate configuration in the " "``neutron.conf`` file." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:132 ../scenario-l3ha-lb.rst:110 msgid "" "Linux bridge agent, L3 agent, DHCP agent, metadata agent, and any " "dependencies." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:136 ../scenario-classic-ovs.rst:150 #: ../scenario-dvr-ovs.rst:106 ../scenario-l3ha-lb.rst:114 #: ../scenario-l3ha-ovs.rst:122 ../scenario-provider-lb.rst:100 #: ../scenario-provider-ovs.rst:106 msgid "OpenStack services - compute nodes" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:140 ../scenario-classic-ovs.rst:154 #: ../scenario-provider-ovs.rst:110 msgid "" "Operational OpenStack Compute controller/management service with appropriate " "configuration to use neutron in the ``nova.conf`` file." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:142 ../scenario-l3ha-lb.rst:120 msgid "Linux bridge agent and any dependencies." msgstr "" #: ../scenario-classic-lb.rst:147 msgid "" "The classic architecture provides basic virtual networking components in " "your environment. Routing among project and external networks resides " "completely on the network node. Although more simple to deploy than other " "architectures, performing all functions on the network node creates a single " "point of failure and potential performance issues. Consider deploying DVR or " "L3 HA architectures in production environments to provide redundancy and " "increase performance. However, the DVR architecture requires Open vSwitch." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:159 ../scenario-classic-ovs.rst:172 #: ../scenario-dvr-ovs.rst:127 msgid "The network node contains the following network components:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:161 ../scenario-l3ha-lb.rst:130 #: ../scenario-provider-lb.rst:119 msgid "" "Linux bridge agent managing virtual switches, connectivity among them, and " "interaction via virtual ports with other network components such as " "namespaces and underlying interfaces." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:164 ../scenario-classic-ovs.rst:177 #: ../scenario-l3ha-lb.rst:133 ../scenario-l3ha-ovs.rst:142 msgid "" "DHCP agent managing the ``qdhcp`` namespaces. The ``qdhcp`` namespaces " "provide DHCP services for instances using project networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:166 ../scenario-classic-ovs.rst:179 msgid "" "L3 agent managing the ``qrouter`` namespaces. The ``qrouter`` namespaces " "provide routing between project and external networks and among project " "networks. They also route metadata traffic between instances and the " "metadata agent." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:170 ../scenario-classic-ovs.rst:183 #: ../scenario-l3ha-lb.rst:139 ../scenario-l3ha-ovs.rst:148 msgid "Metadata agent handling metadata operations for instances." msgstr "" #: ../scenario-classic-lb.rst:178 msgid "" "The compute nodes contain the Linux bridge agent managing virtual switches, " "connectivity among them, and interaction via virtual ports with other " "network components such as namespaces, security groups, and underlying " "interfaces." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:189 ../scenario-classic-ovs.rst:207 #: ../scenario-dvr-ovs.rst:184 ../scenario-l3ha-lb.rst:166 #: ../scenario-l3ha-ovs.rst:177 ../scenario-provider-lb.rst:152 #: ../scenario-provider-ovs.rst:163 msgid "Packet flow" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:192 ../scenario-classic-ovs.rst:210 #: ../scenario-provider-lb.rst:155 ../scenario-provider-ovs.rst:166 msgid "" "*North-south* network traffic travels between an instance and external " "network, typically the Internet. *East-west* network traffic travels between " "instances." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:197 ../scenario-classic-ovs.rst:215 msgid "Case 1: North-south for instances with a fixed IP address" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:199 ../scenario-classic-ovs.rst:217 msgid "" "For instances with a fixed IP address, the network node routes *north-south* " "network traffic between project and external networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:202 ../scenario-classic-lb.rst:298 #: ../scenario-classic-ovs.rst:220 ../scenario-classic-ovs.rst:312 #: ../scenario-dvr-ovs.rst:193 ../scenario-dvr-ovs.rst:280 #: ../scenario-provider-lb.rst:170 ../scenario-provider-ovs.rst:186 msgid "External network" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:204 ../scenario-classic-lb.rst:300 #: ../scenario-classic-ovs.rst:222 ../scenario-classic-ovs.rst:314 #: ../scenario-dvr-ovs.rst:195 ../scenario-dvr-ovs.rst:282 #: ../scenario-provider-lb.rst:172 ../scenario-provider-ovs.rst:188 msgid "Network 203.0.113.0/24" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:205 ../scenario-classic-lb.rst:301 #: ../scenario-classic-ovs.rst:223 ../scenario-classic-ovs.rst:315 msgid "IP address allocation from 203.0.113.101 to 203.0.113.200" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:206 ../scenario-classic-lb.rst:302 #: ../scenario-classic-ovs.rst:224 ../scenario-classic-ovs.rst:316 #: ../scenario-dvr-ovs.rst:198 ../scenario-dvr-ovs.rst:285 msgid "Project network router interface 203.0.113.101 *TR*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:208 ../scenario-classic-lb.rst:304 #: ../scenario-classic-lb.rst:472 ../scenario-classic-ovs.rst:226 #: ../scenario-classic-ovs.rst:318 ../scenario-classic-ovs.rst:545 #: ../scenario-dvr-ovs.rst:201 ../scenario-dvr-ovs.rst:287 msgid "Project network" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:210 ../scenario-classic-lb.rst:306 #: ../scenario-classic-ovs.rst:228 ../scenario-classic-ovs.rst:320 #: ../scenario-dvr-ovs.rst:203 ../scenario-dvr-ovs.rst:289 #: ../scenario-dvr-ovs.rst:377 msgid "Network 192.168.1.0/24" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:211 ../scenario-classic-lb.rst:307 #: ../scenario-classic-ovs.rst:229 ../scenario-classic-ovs.rst:321 #: ../scenario-dvr-ovs.rst:204 ../scenario-dvr-ovs.rst:290 msgid "Gateway 192.168.1.1 with MAC address *TG*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:213 ../scenario-classic-lb.rst:309 #: ../scenario-classic-lb.rst:400 ../scenario-classic-lb.rst:476 #: ../scenario-classic-ovs.rst:231 ../scenario-classic-ovs.rst:323 #: ../scenario-classic-ovs.rst:415 ../scenario-classic-ovs.rst:549 #: ../scenario-dvr-ovs.rst:206 ../scenario-dvr-ovs.rst:385 #: ../scenario-provider-lb.rst:179 ../scenario-provider-lb.rst:232 #: ../scenario-provider-lb.rst:296 ../scenario-provider-ovs.rst:195 #: ../scenario-provider-ovs.rst:252 ../scenario-provider-ovs.rst:323 msgid "Compute node 1" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:215 ../scenario-classic-ovs.rst:233 #: ../scenario-dvr-ovs.rst:208 ../scenario-dvr-ovs.rst:387 msgid "Instance 1 192.168.1.11 with MAC address *I1*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:217 ../scenario-classic-lb.rst:314 #: ../scenario-classic-ovs.rst:235 ../scenario-classic-ovs.rst:328 #: ../scenario-dvr-ovs.rst:211 ../scenario-dvr-ovs.rst:299 msgid "Instance 1 resides on compute node 1 and uses a project network." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:218 ../scenario-classic-ovs.rst:236 #: ../scenario-dvr-ovs.rst:212 ../scenario-provider-lb.rst:184 #: ../scenario-provider-ovs.rst:200 msgid "The instance sends a packet to a host on the external network." msgstr "" #: ../scenario-classic-lb.rst:221 ../scenario-classic-lb.rst:318 msgid "" "Although the diagram shows both VXLAN and VLAN project networks, the packet " "flow only considers one instance using a VXLAN project network." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:224 ../scenario-classic-lb.rst:350 #: ../scenario-classic-lb.rst:413 ../scenario-classic-lb.rst:490 #: ../scenario-classic-ovs.rst:238 ../scenario-classic-ovs.rst:365 #: ../scenario-classic-ovs.rst:428 ../scenario-classic-ovs.rst:563 #: ../scenario-dvr-ovs.rst:218 ../scenario-dvr-ovs.rst:404 #: ../scenario-provider-lb.rst:244 ../scenario-provider-lb.rst:309 #: ../scenario-provider-ovs.rst:264 ../scenario-provider-ovs.rst:336 msgid "The following steps involve compute node 1:" msgstr "" #: ../scenario-classic-lb.rst:226 ../scenario-classic-lb.rst:255 #: ../scenario-classic-lb.rst:331 ../scenario-classic-lb.rst:352 msgid "For VXLAN project networks:" msgstr "" #: ../scenario-classic-lb.rst:228 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the tunnel " "bridge ``qbr``. The packet contains destination MAC address *TG* because the " "destination resides on another network." msgstr "" #: ../scenario-classic-lb.rst:231 ../scenario-classic-lb.rst:418 #: ../scenario-classic-lb.rst:495 msgid "" "Security group rules (2) on the tunnel bridge ``qbr`` handle state tracking " "for the packet." msgstr "" #: ../scenario-classic-lb.rst:233 ../scenario-classic-lb.rst:420 #: ../scenario-classic-lb.rst:497 msgid "" "The tunnel bridge ``qbr`` forwards the packet to the logical tunnel " "interface ``vxlan-sid`` (3) where *sid* contains the project network " "segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:236 ../scenario-classic-lb.rst:423 msgid "The physical tunnel interface forwards the packet to the network node." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:239 ../scenario-classic-lb.rst:266 #: ../scenario-classic-lb.rst:340 ../scenario-classic-lb.rst:364 #: ../scenario-classic-ovs.rst:249 ../scenario-classic-ovs.rst:269 #: ../scenario-classic-ovs.rst:347 ../scenario-classic-ovs.rst:367 #: ../scenario-classic-ovs.rst:439 ../scenario-classic-ovs.rst:459 #: ../scenario-classic-ovs.rst:487 ../scenario-classic-ovs.rst:507 #: ../scenario-classic-ovs.rst:574 ../scenario-classic-ovs.rst:594 msgid "For VLAN project networks:" msgstr "" #: ../scenario-classic-lb.rst:241 msgid "" "The instance 1 ``tap`` interface forwards the packet to the VLAN bridge " "``qbr``. The packet contains destination MAC address *TG* because the " "destination resides on another network." msgstr "" #: ../scenario-classic-lb.rst:244 msgid "" "Security group rules on the VLAN bridge ``qbr`` handle state tracking for " "the packet." msgstr "" #: ../scenario-classic-lb.rst:246 ../scenario-classic-lb.rst:344 msgid "" "The VLAN bridge ``qbr`` forwards the packet to the logical VLAN interface " "``device.sid`` where *device* references the underlying physical VLAN " "interface and *sid* contains the project network segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:250 msgid "" "The logical VLAN interface ``device.sid`` forwards the packet to the network " "node via the physical VLAN interface." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:253 ../scenario-classic-lb.rst:321 #: ../scenario-classic-lb.rst:426 ../scenario-classic-ovs.rst:267 #: ../scenario-classic-ovs.rst:331 ../scenario-classic-ovs.rst:457 #: ../scenario-dvr-ovs.rst:245 msgid "The following steps involve the network node:" msgstr "" #: ../scenario-classic-lb.rst:257 ../scenario-classic-lb.rst:428 #: ../scenario-classic-lb.rst:504 msgid "" "The physical tunnel interface forwards the packet to the logical tunnel " "interface ``vxlan-sid`` (4) where *sid* contains the project network " "segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:260 ../scenario-classic-lb.rst:357 #: ../scenario-classic-lb.rst:431 ../scenario-classic-lb.rst:507 msgid "" "The logical tunnel interface ``vxlan-sid`` forwards the packet to the tunnel " "bridge ``qbr``." msgstr "" #: ../scenario-classic-lb.rst:262 msgid "" "The tunnel bridge ``qbr`` forwards the packet to the ``qr`` interface (5) in " "the router namespace ``qrouter``. The ``qr`` interface contains the project " "network router interface IP address *TG*." msgstr "" #: ../scenario-classic-lb.rst:268 ../scenario-classic-lb.rst:366 msgid "" "The physical VLAN interface forwards the packet to the logical VLAN " "interface ``device.sid`` where *device* references the underlying physical " "VLAN interface and *sid* contains the project network segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:272 ../scenario-classic-lb.rst:370 msgid "" "The logical VLAN interface ``device.sid`` forwards the packet to the VLAN " "bridge ``qbr``." msgstr "" #: ../scenario-classic-lb.rst:274 msgid "" "The VLAN bridge ``qbr`` forwards the packet to the ``qr`` interface in the " "router namespace ``qrouter``. The ``qr`` interface contains the project " "network 1 gateway IP address *TG*." msgstr "" #: ../scenario-classic-lb.rst:278 msgid "" "The *iptables* service (6) performs SNAT on the packet using the ``qg`` " "interface (7) as the source IP address. The ``qg`` interface contains the " "project network router interface IP address *TR*." msgstr "" #: ../scenario-classic-lb.rst:281 msgid "" "The router namespace ``qrouter`` forwards the packet to the external bridge " "``qbr``." msgstr "" #: ../scenario-classic-lb.rst:283 msgid "" "The external bridge ``qbr`` forwards the packet to the external network via " "the physical external interface." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:287 ../scenario-classic-lb.rst:378 #: ../scenario-classic-lb.rst:460 ../scenario-classic-lb.rst:515 #: ../scenario-classic-ovs.rst:301 ../scenario-classic-ovs.rst:393 #: ../scenario-classic-ovs.rst:533 ../scenario-classic-ovs.rst:620 #: ../scenario-dvr-ovs.rst:265 ../scenario-provider-lb.rst:211 #: ../scenario-provider-lb.rst:281 ../scenario-provider-lb.rst:341 #: ../scenario-provider-ovs.rst:231 ../scenario-provider-ovs.rst:308 #: ../scenario-provider-ovs.rst:374 msgid "Return traffic follows similar steps in reverse." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:293 ../scenario-classic-ovs.rst:307 msgid "Case 2: North-south for instances with a floating IP address" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:295 ../scenario-classic-ovs.rst:309 msgid "" "For instances with a floating IP address, the network node routes *north-" "south* network traffic between project and external networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:311 ../scenario-classic-ovs.rst:325 #: ../scenario-dvr-ovs.rst:294 msgid "" "Instance 1 192.168.1.11 with MAC address *I1* and floating IP address " "203.0.113.102 *F1*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:315 ../scenario-classic-ovs.rst:329 msgid "The instance receives a packet from a host on the external network." msgstr "" #: ../scenario-classic-lb.rst:323 msgid "" "The physical external interface forwards the packet to the external bridge " "``qbr``." msgstr "" #: ../scenario-classic-lb.rst:325 msgid "" "The external bridge ``qbr`` forwards the packet to the ``qg`` interface (1) " "in the router namespace ``qrouter``. The ``qg`` interface contains the " "instance floating IP address *F1*." msgstr "" #: ../scenario-classic-lb.rst:328 msgid "" "The *iptables* service (2) performs DNAT on the packet using the ``qr`` " "interface (3) as the source IP address. The ``qr`` interface contains the " "project network gateway IP address *TR*." msgstr "" #: ../scenario-classic-lb.rst:333 msgid "" "The router namespace ``qrouter`` forwards the packet to the tunnel bridge " "``qbr``." msgstr "" #: ../scenario-classic-lb.rst:335 msgid "" "The tunnel bridge ``qbr`` forwards the packet to the logical tunnel " "interface ``vxlan-sid`` (4) where *sid* contains the project network " "segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:338 msgid "The physical tunnel interface forwards the packet to compute node 1." msgstr "" #: ../scenario-classic-lb.rst:342 ../scenario-classic-lb.rst:440 msgid "" "The router namespace ``qrouter`` forwards the packet to the VLAN bridge " "``qbr``." msgstr "" #: ../scenario-classic-lb.rst:348 msgid "The physical VLAN interface forwards the packet to compute node 1." msgstr "" #: ../scenario-classic-lb.rst:354 msgid "" "The physical tunnel interface forwards the packet to the logical tunnel " "interface ``vxlan-sid`` (5) where *sid* contains the project network " "segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:359 msgid "" "Security group rules (6) on the tunnel bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-classic-lb.rst:361 msgid "" "The tunnel bridge ``qbr`` forwards the packet to the ``tap`` interface (7) " "on instance 1." msgstr "" #: ../scenario-classic-lb.rst:372 msgid "" "Security group rules on the VLAN bridge ``qbr`` handle firewalling and state " "tracking for the packet." msgstr "" #: ../scenario-classic-lb.rst:374 msgid "" "The VLAN bridge ``qbr`` forwards the packet to the ``tap`` interface on " "instance 1." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:384 ../scenario-classic-ovs.rst:399 msgid "Case 3: East-west for instances on different networks" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:386 ../scenario-classic-ovs.rst:401 msgid "" "For instances with a fixed or floating IP address, the network node routes " "*east-west* network traffic among project networks using the same project " "router." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:390 ../scenario-classic-ovs.rst:405 #: ../scenario-dvr-ovs.rst:375 msgid "Project network 1" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:392 ../scenario-classic-lb.rst:474 #: ../scenario-classic-ovs.rst:407 ../scenario-classic-ovs.rst:547 msgid "Network: 192.168.1.0/24" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:393 ../scenario-classic-ovs.rst:408 msgid "Gateway: 192.168.1.1 with MAC address *TG1*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:395 ../scenario-classic-ovs.rst:410 #: ../scenario-dvr-ovs.rst:380 msgid "Project network 2" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:397 ../scenario-classic-ovs.rst:412 msgid "Network: 192.168.2.0/24" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:398 ../scenario-classic-ovs.rst:413 msgid "Gateway: 192.168.2.1 with MAC address *TG2*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:402 ../scenario-classic-lb.rst:478 #: ../scenario-classic-ovs.rst:417 ../scenario-classic-ovs.rst:551 msgid "Instance 1: 192.168.1.11 with MAC address *I1*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:404 ../scenario-classic-lb.rst:480 #: ../scenario-classic-ovs.rst:419 ../scenario-classic-ovs.rst:553 #: ../scenario-dvr-ovs.rst:390 ../scenario-provider-lb.rst:236 #: ../scenario-provider-lb.rst:300 ../scenario-provider-ovs.rst:256 #: ../scenario-provider-ovs.rst:327 msgid "Compute node 2" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:406 ../scenario-classic-ovs.rst:421 msgid "Instance 2: 192.168.2.11 with MAC address *I2*" msgstr "" #: ../scenario-classic-lb.rst:408 msgid "Instance 1 resides on compute node 1 and uses VXLAN project network 1." msgstr "" #: ../scenario-classic-lb.rst:409 msgid "Instance 2 resides on compute node 2 and uses VLAN project network 2." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:410 ../scenario-classic-ovs.rst:425 msgid "Both project networks reside on the same router." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:411 ../scenario-classic-lb.rst:487 #: ../scenario-classic-ovs.rst:426 ../scenario-classic-ovs.rst:560 #: ../scenario-dvr-ovs.rst:398 ../scenario-provider-lb.rst:242 #: ../scenario-provider-lb.rst:307 ../scenario-provider-ovs.rst:262 #: ../scenario-provider-ovs.rst:334 msgid "Instance 1 sends a packet to instance 2." msgstr "" #: ../scenario-classic-lb.rst:415 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the tunnel " "bridge ``qbr``. The packet contains destination MAC address *TG1* because " "the destination resides on another network." msgstr "" #: ../scenario-classic-lb.rst:433 msgid "" "The tunnel bridge ``qbr`` forwards the packet to the ``qr-1`` interface (5) " "in the router namespace ``qrouter``. The ``qr-1`` interface contains the " "project network 1 gateway IP address *TG1*." msgstr "" #: ../scenario-classic-lb.rst:437 msgid "" "The router namespace ``qrouter`` routes the packet (6) to the ``qr-2`` " "interface (7). The ``qr-2`` interface contains the project network 2 gateway " "IP address *TG2*." msgstr "" #: ../scenario-classic-lb.rst:442 msgid "" "The VLAN bridge ``qbr`` forwards the packet to the logical VLAN interface " "``vlan.sid`` (8) where *sid* contains the project network segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:445 msgid "The physical VLAN interface forwards the packet to compute node 2." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:447 ../scenario-classic-lb.rst:502 #: ../scenario-classic-ovs.rst:505 ../scenario-classic-ovs.rst:592 #: ../scenario-dvr-ovs.rst:432 ../scenario-provider-lb.rst:268 #: ../scenario-provider-lb.rst:327 ../scenario-provider-ovs.rst:292 #: ../scenario-provider-ovs.rst:358 msgid "The following steps involve compute node 2:" msgstr "" #: ../scenario-classic-lb.rst:449 msgid "" "The physical VLAN interface forwards the packet to the logical VLAN " "interface ``vlan.sid`` (9) where *sid* contains the project network " "segmentation ID." msgstr "" #: ../scenario-classic-lb.rst:452 msgid "" "The logical VLAN interface ``vlan.sid`` forwards the packet to the VLAN " "bridge ``qbr``." msgstr "" #: ../scenario-classic-lb.rst:454 msgid "" "Security group rules (10) on the VLAN bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-classic-lb.rst:456 msgid "" "The VLAN bridge ``qbr`` forwards the packet to the ``tap`` interface (11) on " "instance 2." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:466 ../scenario-classic-ovs.rst:539 msgid "Case 4: East-west for instances on the same network" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:468 ../scenario-classic-ovs.rst:541 msgid "" "For instances with a fixed or floating IP address, the project network " "switches *east-west* network traffic among instances without using a project " "router on the network node." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:482 ../scenario-classic-ovs.rst:555 msgid "Instance 2: 192.168.1.12 with MAC address *I2*" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:484 ../scenario-classic-ovs.rst:557 #: ../scenario-provider-lb.rst:304 ../scenario-provider-ovs.rst:331 msgid "Instance 1 resides on compute node 1." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:485 ../scenario-classic-ovs.rst:558 #: ../scenario-provider-lb.rst:305 ../scenario-provider-ovs.rst:332 msgid "Instance 2 resides on compute node 2." msgstr "" #: ../scenario-classic-lb.rst:486 msgid "Both instances use the same VXLAN project network." msgstr "" #: ../scenario-classic-lb.rst:488 msgid "The Linux bridge agent handles switching within the project network." msgstr "" #: ../scenario-classic-lb.rst:492 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the tunnel " "bridge ``qbr``. The packet contains destination MAC address *I2* because the " "destination resides the same network." msgstr "" #: ../scenario-classic-lb.rst:500 msgid "The physical tunnel interface forwards the packet to compute node 2." msgstr "" #: ../scenario-classic-lb.rst:509 msgid "" "Security group rules (5) on the tunnel bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-classic-lb.rst:511 msgid "" "The tunnel bridge ``qbr`` forwards the packet to the ``tap`` interface (6) " "on instance 2." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:521 ../scenario-classic-ovs.rst:626 #: ../scenario-dvr-ovs.rst:462 ../scenario-l3ha-lb.rst:190 #: ../scenario-l3ha-ovs.rst:201 ../scenario-provider-lb.rst:347 #: ../scenario-provider-ovs.rst:380 msgid "Example configuration" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:523 ../scenario-classic-ovs.rst:628 #: ../scenario-dvr-ovs.rst:464 ../scenario-l3ha-lb.rst:192 #: ../scenario-l3ha-ovs.rst:203 ../scenario-provider-lb.rst:349 #: ../scenario-provider-ovs.rst:382 msgid "" "Use the following example configuration as a template to deploy this " "scenario in your environment." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:527 ../scenario-classic-ovs.rst:632 #: ../scenario-dvr-ovs.rst:471 ../scenario-l3ha-lb.rst:196 #: ../scenario-l3ha-ovs.rst:207 ../scenario-provider-lb.rst:358 #: ../scenario-provider-ovs.rst:391 msgid "Controller node" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:529 ../scenario-classic-ovs.rst:634 #: ../scenario-dvr-ovs.rst:473 ../scenario-l3ha-lb.rst:198 #: ../scenario-l3ha-ovs.rst:209 msgid "" "Configure common options. Edit the :file:`/etc/neutron/neutron.conf` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:539 ../scenario-classic-ovs.rst:644 #: ../scenario-dvr-ovs.rst:490 ../scenario-l3ha-lb.rst:214 #: ../scenario-l3ha-ovs.rst:225 msgid "" "Configure the ML2 plug-in. Edit the :file:`/etc/neutron/plugins/ml2/ml2_conf." "ini` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:562 ../scenario-l3ha-lb.rst:237 msgid "" "Replace ``MIN_VLAN_ID``, ``MAX_VLAN_ID``, ``MIN_VXLAN_ID``, and " "``MAX_VXLAN_ID`` with VLAN and VXLAN ID minimum and maximum values suitable " "for your environment." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:567 ../scenario-classic-ovs.rst:675 #: ../scenario-l3ha-lb.rst:242 ../scenario-l3ha-ovs.rst:256 msgid "" "The first value in the ``tenant_network_types`` option becomes the default " "project network type when a regular user creates a network." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:571 ../scenario-classic-ovs.rst:679 #: ../scenario-l3ha-lb.rst:246 ../scenario-l3ha-ovs.rst:260 msgid "" "The ``external`` value in the ``network_vlan_ranges`` option lacks VLAN ID " "ranges to support use of arbitrary VLAN IDs by administrative users." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:574 ../scenario-classic-lb.rst:666 #: ../scenario-classic-lb.rst:708 ../scenario-classic-ovs.rst:682 #: ../scenario-classic-ovs.rst:769 ../scenario-classic-ovs.rst:808 #: ../scenario-dvr-ovs.rst:529 ../scenario-dvr-ovs.rst:619 #: ../scenario-dvr-ovs.rst:687 ../scenario-l3ha-lb.rst:249 #: ../scenario-l3ha-lb.rst:341 ../scenario-l3ha-lb.rst:383 #: ../scenario-l3ha-ovs.rst:263 ../scenario-l3ha-ovs.rst:351 #: ../scenario-l3ha-ovs.rst:390 ../scenario-provider-lb.rst:437 #: ../scenario-provider-lb.rst:474 ../scenario-provider-ovs.rst:484 #: ../scenario-provider-ovs.rst:535 msgid "Start the following services:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:579 ../scenario-classic-ovs.rst:687 #: ../scenario-dvr-ovs.rst:534 msgid "Network node" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:581 ../scenario-classic-lb.rst:676 #: ../scenario-classic-ovs.rst:689 ../scenario-classic-ovs.rst:780 #: ../scenario-dvr-ovs.rst:536 ../scenario-dvr-ovs.rst:630 #: ../scenario-l3ha-lb.rst:256 ../scenario-l3ha-lb.rst:351 #: ../scenario-l3ha-ovs.rst:270 ../scenario-l3ha-ovs.rst:362 #: ../scenario-provider-lb.rst:360 ../scenario-provider-lb.rst:446 #: ../scenario-provider-ovs.rst:393 ../scenario-provider-ovs.rst:493 msgid "Configure common options. Edit the ``/etc/neutron/neutron.conf`` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:588 ../scenario-classic-lb.rst:683 #: ../scenario-l3ha-lb.rst:263 ../scenario-l3ha-lb.rst:358 #: ../scenario-provider-lb.rst:408 ../scenario-provider-lb.rst:453 msgid "" "Configure the Linux bridge agent. Edit the ``/etc/neutron/plugins/ml2/" "linuxbridge_agent.ini`` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:608 ../scenario-l3ha-lb.rst:283 #: ../scenario-l3ha-lb.rst:378 msgid "" "Replace ``PROJECT_VLAN_INTERFACE`` and ``EXTERNAL_INTERFACE`` with the name " "of the underlying interface that handles VLAN project networks and external " "networks, respectively. Replace ``TUNNEL_INTERFACE_IP_ADDRESS`` with the IP " "address of the interface that handles project tunnel networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:613 ../scenario-classic-ovs.rst:717 #: ../scenario-dvr-ovs.rst:566 ../scenario-dvr-ovs.rst:660 #: ../scenario-l3ha-lb.rst:288 ../scenario-l3ha-ovs.rst:298 msgid "" "Configure the L3 agent. Edit the :file:`/etc/neutron/l3_agent.ini` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:625 ../scenario-classic-ovs.rst:728 #: ../scenario-dvr-ovs.rst:578 ../scenario-dvr-ovs.rst:672 #: ../scenario-l3ha-lb.rst:300 ../scenario-l3ha-ovs.rst:310 msgid "The ``external_network_bridge`` option intentionally contains no value." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:628 ../scenario-classic-ovs.rst:731 #: ../scenario-dvr-ovs.rst:581 ../scenario-l3ha-lb.rst:303 #: ../scenario-l3ha-ovs.rst:313 msgid "" "Configure the DHCP agent. Edit the :file:`/etc/neutron/dhcp_agent.ini` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:639 ../scenario-l3ha-lb.rst:314 msgid "(Optional) Reduce MTU for VXLAN project networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:641 ../scenario-classic-ovs.rst:744 #: ../scenario-dvr-ovs.rst:594 ../scenario-l3ha-lb.rst:316 #: ../scenario-l3ha-ovs.rst:326 msgid "Edit the :file:`/etc/neutron/dhcp_agent.ini` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:648 ../scenario-classic-ovs.rst:751 #: ../scenario-dvr-ovs.rst:601 ../scenario-l3ha-lb.rst:323 #: ../scenario-l3ha-ovs.rst:333 msgid "Edit the :file:`/etc/neutron/dnsmasq-neutron.conf` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:654 ../scenario-classic-ovs.rst:757 #: ../scenario-dvr-ovs.rst:607 ../scenario-dvr-ovs.rst:675 #: ../scenario-l3ha-lb.rst:329 ../scenario-l3ha-ovs.rst:339 msgid "" "Configure the metadata agent. Edit the :file:`/etc/neutron/metadata_agent." "ini` file:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:664 ../scenario-classic-ovs.rst:767 #: ../scenario-dvr-ovs.rst:617 ../scenario-dvr-ovs.rst:685 #: ../scenario-l3ha-lb.rst:339 ../scenario-l3ha-ovs.rst:349 msgid "Replace ``METADATA_SECRET`` with a suitable value for your environment." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:668 ../scenario-classic-lb.rst:710 #: ../scenario-l3ha-lb.rst:343 ../scenario-l3ha-lb.rst:385 #: ../scenario-provider-lb.rst:440 ../scenario-provider-lb.rst:476 msgid "Linux bridge agent" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:669 ../scenario-classic-ovs.rst:773 #: ../scenario-dvr-ovs.rst:623 ../scenario-dvr-ovs.rst:691 #: ../scenario-l3ha-lb.rst:344 ../scenario-l3ha-ovs.rst:355 msgid "L3 agent" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:670 ../scenario-classic-ovs.rst:774 #: ../scenario-dvr-ovs.rst:624 ../scenario-l3ha-lb.rst:345 #: ../scenario-l3ha-ovs.rst:356 ../scenario-provider-lb.rst:441 #: ../scenario-provider-ovs.rst:488 msgid "DHCP agent" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:671 ../scenario-classic-ovs.rst:775 #: ../scenario-dvr-ovs.rst:625 ../scenario-dvr-ovs.rst:692 #: ../scenario-l3ha-lb.rst:346 ../scenario-l3ha-ovs.rst:357 msgid "Metadata agent" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:674 ../scenario-classic-ovs.rst:778 #: ../scenario-dvr-ovs.rst:628 ../scenario-l3ha-lb.rst:349 #: ../scenario-l3ha-ovs.rst:360 ../scenario-provider-lb.rst:444 #: ../scenario-provider-ovs.rst:491 msgid "Compute nodes" msgstr "" #: ../scenario-classic-lb.rst:703 msgid "" "Replace ``PROJECT_VLAN_INTERFACE`` with the name of the underlying interface " "that handles VLAN project networks and external networks, respectively. " "Replace ``TUNNEL_INTERFACE_IP_ADDRESS`` with the IP address of the interface " "that handles VXLAN project networks." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:713 ../scenario-classic-ovs.rst:814 #: ../scenario-dvr-ovs.rst:695 ../scenario-l3ha-lb.rst:388 #: ../scenario-l3ha-ovs.rst:396 ../scenario-provider-lb.rst:479 #: ../scenario-provider-ovs.rst:540 msgid "Verify service operation" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:716 ../scenario-classic-ovs.rst:817 #: ../scenario-dvr-ovs.rst:698 ../scenario-l3ha-lb.rst:391 #: ../scenario-l3ha-ovs.rst:399 ../scenario-provider-lb.rst:482 #: ../scenario-provider-ovs.rst:543 msgid "Verify presence and operation of the agents:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:733 ../scenario-classic-ovs.rst:834 #: ../scenario-dvr-ovs.rst:719 ../scenario-l3ha-lb.rst:412 #: ../scenario-l3ha-ovs.rst:420 ../scenario-provider-lb.rst:497 #: ../scenario-provider-ovs.rst:558 msgid "Create initial networks" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:735 ../scenario-classic-ovs.rst:836 #: ../scenario-dvr-ovs.rst:721 ../scenario-l3ha-lb.rst:414 #: ../scenario-l3ha-ovs.rst:422 msgid "" "This example creates a flat external network and a VXLAN project network." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:738 ../scenario-classic-ovs.rst:839 #: ../scenario-dvr-ovs.rst:724 ../scenario-l3ha-lb.rst:417 #: ../scenario-l3ha-ovs.rst:425 msgid "Create the external network:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:761 ../scenario-classic-ovs.rst:862 #: ../scenario-dvr-ovs.rst:747 ../scenario-l3ha-lb.rst:440 #: ../scenario-l3ha-ovs.rst:448 msgid "Create a subnet on the external network:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:788 ../scenario-l3ha-lb.rst:467 msgid "" "The example configuration contains ``vlan`` as the first project network " "type. Only an administrative user can create other types of networks such as " "VXLAN. The following commands use the ``admin`` project credentials to " "create a VXLAN project network." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:793 ../scenario-classic-ovs.rst:894 #: ../scenario-dvr-ovs.rst:779 ../scenario-l3ha-lb.rst:472 #: ../scenario-l3ha-ovs.rst:480 msgid "" "Obtain the ID of a regular project. For example, using the ``demo`` project:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:807 ../scenario-classic-ovs.rst:908 #: ../scenario-dvr-ovs.rst:793 ../scenario-l3ha-ovs.rst:494 msgid "Create the project network:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:830 ../scenario-classic-lb.rst:933 #: ../scenario-classic-ovs.rst:931 ../scenario-classic-ovs.rst:1035 #: ../scenario-l3ha-lb.rst:510 ../scenario-l3ha-ovs.rst:764 #: ../scenario-provider-lb.rst:568 ../scenario-provider-ovs.rst:629 msgid "" "Source the regular project credentials. The following steps use the ``demo`` " "project." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:832 ../scenario-classic-ovs.rst:933 #: ../scenario-dvr-ovs.rst:817 ../scenario-l3ha-lb.rst:512 #: ../scenario-l3ha-ovs.rst:520 msgid "Create a subnet on the project network:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:857 ../scenario-classic-ovs.rst:958 #: ../scenario-l3ha-lb.rst:537 ../scenario-l3ha-ovs.rst:545 msgid "Create a project router:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:874 ../scenario-classic-ovs.rst:976 #: ../scenario-l3ha-ovs.rst:570 msgid "Add the project subnet as an interface on the router:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:881 ../scenario-classic-ovs.rst:983 #: ../scenario-l3ha-lb.rst:569 ../scenario-l3ha-ovs.rst:577 msgid "Add a gateway to the external network on the router:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:889 ../scenario-classic-ovs.rst:991 #: ../scenario-dvr-ovs.rst:882 ../scenario-l3ha-lb.rst:577 #: ../scenario-l3ha-ovs.rst:585 ../scenario-provider-lb.rst:556 #: ../scenario-provider-ovs.rst:617 msgid "Verify network operation" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:891 ../scenario-classic-ovs.rst:993 msgid "" "On the network node, verify creation of the ``qrouter`` and ``qdhcp`` " "namespaces:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:901 ../scenario-classic-ovs.rst:1003 #: ../scenario-provider-lb.rst:566 ../scenario-provider-ovs.rst:627 msgid "The ``qdhcp`` namespace might not exist until launching an instance." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:903 ../scenario-classic-ovs.rst:1005 #: ../scenario-dvr-ovs.rst:898 ../scenario-l3ha-lb.rst:726 #: ../scenario-l3ha-ovs.rst:732 msgid "" "Determine the external network gateway IP address for the project network on " "the router, typically the lowest IP address in the external subnet IP " "allocation range:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:917 ../scenario-classic-ovs.rst:1019 #: ../scenario-dvr-ovs.rst:912 ../scenario-l3ha-lb.rst:742 #: ../scenario-l3ha-ovs.rst:748 msgid "" "On the controller node or any host with access to the external network, ping " "the external network gateway IP address on the project router:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:935 ../scenario-classic-ovs.rst:1037 #: ../scenario-dvr-ovs.rst:929 msgid "Launch an instance with an interface on the project network." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:936 ../scenario-classic-ovs.rst:1038 #: ../scenario-dvr-ovs.rst:938 ../scenario-l3ha-lb.rst:817 #: ../scenario-l3ha-ovs.rst:823 msgid "Obtain console access to the instance." msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:938 ../scenario-classic-ovs.rst:1040 #: ../scenario-dvr-ovs.rst:940 ../scenario-l3ha-lb.rst:819 #: ../scenario-l3ha-ovs.rst:825 msgid "Test connectivity to the project router:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:953 ../scenario-classic-ovs.rst:1055 #: ../scenario-dvr-ovs.rst:955 ../scenario-l3ha-lb.rst:834 #: ../scenario-l3ha-ovs.rst:840 ../scenario-provider-lb.rst:661 #: ../scenario-provider-ovs.rst:722 msgid "Test connectivity to the Internet:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:968 ../scenario-classic-ovs.rst:1070 #: ../scenario-dvr-ovs.rst:970 ../scenario-l3ha-lb.rst:760 #: ../scenario-l3ha-ovs.rst:766 ../scenario-provider-lb.rst:570 #: ../scenario-provider-ovs.rst:631 msgid "" "Create the appropriate security group rules to allow ping and SSH access to " "the instance. For example:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:987 ../scenario-classic-ovs.rst:1089 #: ../scenario-dvr-ovs.rst:989 ../scenario-l3ha-lb.rst:849 #: ../scenario-l3ha-ovs.rst:855 msgid "Create a floating IP address on the external network:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:1005 ../scenario-classic-ovs.rst:1107 #: ../scenario-dvr-ovs.rst:1008 ../scenario-l3ha-lb.rst:868 #: ../scenario-l3ha-ovs.rst:874 msgid "Associate the floating IP address with the instance:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:1011 ../scenario-classic-ovs.rst:1113 #: ../scenario-dvr-ovs.rst:1014 ../scenario-l3ha-lb.rst:874 #: ../scenario-l3ha-ovs.rst:880 msgid "Verify addition of the floating IP address to the instance:" msgstr "" # #-#-#-#-# scenario-classic-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-lb.rst:1022 ../scenario-classic-ovs.rst:1124 #: ../scenario-dvr-ovs.rst:1033 ../scenario-l3ha-lb.rst:885 #: ../scenario-l3ha-ovs.rst:891 msgid "" "On the controller node or any host with access to the external network, ping " "the floating IP address associated with the instance:" msgstr "" #: ../scenario-classic-ovs.rst:5 msgid "Scenario: Classic with Open vSwitch" msgstr "" #: ../scenario-classic-ovs.rst:7 msgid "" "This scenario describes a classic implementation of the OpenStack Networking " "service using the ML2 plug-in with Open vSwitch (OVS)." msgstr "" #: ../scenario-classic-ovs.rst:17 msgid "" "Project networks provide connectivity to instances for a particular project. " "Regular (non-privileged) users can manage project networks within the " "allocation that an administrator or operator defines for them. Project " "networks can use VLAN, GRE, or VXLAN transport methods depending on the " "allocation. Project networks generally use private IP address ranges " "(RFC1918) and lack connectivity to external networks such as the Internet. " "Networking refers to IP addresses on project networks as *fixed* IP " "addresses." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:59 ../scenario-l3ha-ovs.rst:30 msgid "" "The example configuration creates one flat external network and one VXLAN " "project (tenant) network. However, this configuration also supports VLAN " "external networks, VLAN project networks, and GRE project networks." msgstr "" #: ../scenario-classic-ovs.rst:80 msgid "" "One network node with four network interfaces: management, project tunnel " "networks, VLAN project networks, and external (typically the Internet). The " "Open vSwitch bridge ``br-vlan`` must contain a port on the VLAN interface " "and Open vSwitch bridge ``br-ex`` must contain a port on the external " "interface." msgstr "" #: ../scenario-classic-ovs.rst:85 msgid "" "At least one compute node with three network interfaces: management, project " "tunnel networks, and VLAN project networks. The Open vSwitch bridge ``br-" "vlan`` must contain a port on the VLAN interface." msgstr "" #: ../scenario-classic-ovs.rst:89 msgid "" "To improve understanding of network traffic flow, the network and compute " "nodes contain a separate network interface for VLAN project networks. In " "production environments, VLAN project networks can use any Open vSwitch " "bridge with access to a network interface. For example, the ``br-tun`` " "bridge." msgstr "" #: ../scenario-classic-ovs.rst:110 msgid "" "For VLAN external and project networks, the physical network infrastructure " "must support VLAN tagging. For best performance with VXLAN and GRE project " "networks, the network infrastructure should support jumbo frames." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:116 ../scenario-dvr-ovs.rst:73 #: ../scenario-l3ha-ovs.rst:88 ../scenario-provider-ovs.rst:82 msgid "" "Linux distributions often package older releases of Open vSwitch that can " "introduce issues during operation with the Networking service. We recommend " "using at least the latest long-term stable (LTS) release of Open vSwitch for " "the best experience and support from Open vSwitch. See ``__ for available releases and the `installation " "instructions `__ " "for building newer releases from source on various distributions." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:125 ../scenario-dvr-ovs.rst:82 #: ../scenario-l3ha-ovs.rst:97 msgid "Implementing VXLAN networks requires Linux kernel 3.13 or newer." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:146 ../scenario-dvr-ovs.rst:102 #: ../scenario-l3ha-ovs.rst:118 msgid "" "Open vSwitch service, Open vSwitch agent, L3 agent, DHCP agent, metadata " "agent, and any dependencies." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:156 ../scenario-l3ha-ovs.rst:129 #: ../scenario-provider-ovs.rst:112 msgid "Open vSwitch service, Open vSwitch agent, and any dependencies." msgstr "" #: ../scenario-classic-ovs.rst:161 msgid "" "The classic architecture provides basic virtual networking components in " "your environment. Routing among project and external networks resides " "completely on the network node. Although more simple to deploy than other " "architectures, performing all functions on the network node creates a single " "point of failure and potential performance issues. Consider deploying DVR or " "L3 HA architectures in production environments to provide redundancy and " "increase performance." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:174 ../scenario-classic-ovs.rst:193 #: ../scenario-dvr-ovs.rst:129 ../scenario-dvr-ovs.rst:155 #: ../scenario-l3ha-ovs.rst:139 ../scenario-l3ha-ovs.rst:158 msgid "" "Open vSwitch agent managing virtual switches, connectivity among them, and " "interaction via virtual ports with other network components such as " "namespaces, Linux bridges, and underlying interfaces." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:191 ../scenario-dvr-ovs.rst:153 #: ../scenario-l3ha-lb.rst:151 ../scenario-provider-lb.rst:135 #: ../scenario-provider-ovs.rst:141 msgid "The compute nodes contain the following network components:" msgstr "" #: ../scenario-classic-ovs.rst:196 msgid "" "Linux bridges handling security groups. Due to limitations with Open vSwitch " "and *iptables*, the Networking service uses a Linux bridge to manage " "security groups for instances." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:240 ../scenario-dvr-ovs.rst:220 #: ../scenario-provider-ovs.rst:204 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the Linux bridge " "``qbr``. The packet contains destination MAC address *TG* because the " "destination resides on another network." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:243 ../scenario-classic-ovs.rst:433 #: ../scenario-dvr-ovs.rst:223 ../scenario-dvr-ovs.rst:409 msgid "" "Security group rules (2) on the Linux bridge ``qbr`` handle state tracking " "for the packet." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:245 ../scenario-classic-ovs.rst:435 #: ../scenario-classic-ovs.rst:570 ../scenario-dvr-ovs.rst:225 #: ../scenario-dvr-ovs.rst:344 ../scenario-dvr-ovs.rst:411 #: ../scenario-provider-ovs.rst:209 ../scenario-provider-ovs.rst:271 #: ../scenario-provider-ovs.rst:343 msgid "" "The Linux bridge ``qbr`` forwards the packet to the Open vSwitch integration " "bridge ``br-int``." msgstr "" #: ../scenario-classic-ovs.rst:247 ../scenario-classic-ovs.rst:345 msgid "" "The Open vSwitch integration bridge ``br-int`` adds the internal tag for the " "project network." msgstr "" #: ../scenario-classic-ovs.rst:251 ../scenario-classic-ovs.rst:349 #: ../scenario-classic-ovs.rst:441 ../scenario-classic-ovs.rst:489 #: ../scenario-classic-ovs.rst:576 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "Open vSwitch VLAN bridge ``br-vlan``." msgstr "" #: ../scenario-classic-ovs.rst:253 ../scenario-classic-ovs.rst:351 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` replaces the internal tag with the " "actual VLAN tag of the project network." msgstr "" #: ../scenario-classic-ovs.rst:255 ../scenario-classic-ovs.rst:445 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` forwards the packet to the network " "node via the VLAN interface." msgstr "" #: ../scenario-classic-ovs.rst:258 ../scenario-classic-ovs.rst:278 #: ../scenario-classic-ovs.rst:356 ../scenario-classic-ovs.rst:376 #: ../scenario-classic-ovs.rst:448 ../scenario-classic-ovs.rst:468 #: ../scenario-classic-ovs.rst:496 ../scenario-classic-ovs.rst:516 #: ../scenario-classic-ovs.rst:583 ../scenario-classic-ovs.rst:603 msgid "For VXLAN and GRE project networks:" msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:260 ../scenario-classic-ovs.rst:358 #: ../scenario-classic-ovs.rst:450 ../scenario-classic-ovs.rst:498 #: ../scenario-classic-ovs.rst:585 ../scenario-dvr-ovs.rst:236 #: ../scenario-dvr-ovs.rst:423 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "Open vSwitch tunnel bridge ``br-tun``." msgstr "" #: ../scenario-classic-ovs.rst:262 ../scenario-classic-ovs.rst:360 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` wraps the packet in a VXLAN or GRE " "tunnel and adds a tag to identify the project network." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:264 ../scenario-classic-ovs.rst:454 #: ../scenario-dvr-ovs.rst:242 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` forwards the packet to the network " "node via the tunnel interface." msgstr "" #: ../scenario-classic-ovs.rst:271 ../scenario-classic-ovs.rst:369 #: ../scenario-classic-ovs.rst:461 ../scenario-classic-ovs.rst:509 #: ../scenario-classic-ovs.rst:596 msgid "" "The VLAN interface forwards the packet to the Open vSwitch VLAN bridge ``br-" "vlan``." msgstr "" #: ../scenario-classic-ovs.rst:273 ../scenario-classic-ovs.rst:371 #: ../scenario-classic-ovs.rst:463 ../scenario-classic-ovs.rst:511 #: ../scenario-classic-ovs.rst:598 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` forwards the packet to the Open " "vSwitch integration bridge ``br-int``." msgstr "" #: ../scenario-classic-ovs.rst:275 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the actual VLAN tag " "of the project network with the internal tag." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:280 ../scenario-classic-ovs.rst:378 #: ../scenario-classic-ovs.rst:470 ../scenario-classic-ovs.rst:518 #: ../scenario-classic-ovs.rst:605 ../scenario-dvr-ovs.rst:247 #: ../scenario-dvr-ovs.rst:434 msgid "" "The tunnel interface forwards the packet to the Open vSwitch tunnel bridge " "``br-tun``." msgstr "" #: ../scenario-classic-ovs.rst:282 ../scenario-classic-ovs.rst:380 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` unwraps the packet and adds the " "internal tag for the project network." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:284 ../scenario-classic-ovs.rst:382 #: ../scenario-classic-ovs.rst:474 ../scenario-classic-ovs.rst:522 #: ../scenario-classic-ovs.rst:609 ../scenario-dvr-ovs.rst:251 #: ../scenario-dvr-ovs.rst:437 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` forwards the packet to the Open " "vSwitch integration bridge ``br-int``." msgstr "" #: ../scenario-classic-ovs.rst:287 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "``qr`` interface (3) in the router namespace ``qrouter``. The ``qr`` " "interface contains the project network gateway IP address *TG*." msgstr "" #: ../scenario-classic-ovs.rst:290 msgid "" "The *iptables* service (4) performs SNAT on the packet using the ``qg`` " "interface (5) as the source IP address. The ``qg`` interface contains the " "project network router interface IP address *TR*." msgstr "" #: ../scenario-classic-ovs.rst:293 msgid "" "The router namespace ``qrouter`` forwards the packet to the Open vSwitch " "integration bridge ``br-int`` via the ``qg`` interface." msgstr "" #: ../scenario-classic-ovs.rst:295 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "Open vSwitch external bridge ``br-ex``." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:297 ../scenario-dvr-ovs.rst:261 #: ../scenario-dvr-ovs.rst:361 msgid "" "The Open vSwitch external bridge ``br-ex`` forwards the packet to the " "external network via the external interface." msgstr "" #: ../scenario-classic-ovs.rst:333 msgid "" "The external interface forwards the packet to the Open vSwitch external " "bridge ``br-ex``." msgstr "" #: ../scenario-classic-ovs.rst:335 msgid "" "The Open vSwitch external bridge ``br-ex`` forwards the packet to the Open " "vSwitch integration bridge ``br-int``." msgstr "" #: ../scenario-classic-ovs.rst:337 msgid "" "The Open vSwitch integration bridge forwards the packet to the ``qg`` " "interface (1) in the router namespace ``qrouter``. The ``qg`` interface " "contains the instance 1 floating IP address *F1*." msgstr "" #: ../scenario-classic-ovs.rst:340 msgid "" "The *iptables* service (2) performs DNAT on the packet using the ``qr`` " "interface (3) as the source IP address. The ``qr`` interface contains the " "project network router interface IP address *TR1*." msgstr "" #: ../scenario-classic-ovs.rst:343 ../scenario-classic-ovs.rst:483 msgid "" "The router namespace ``qrouter`` forwards the packet to the Open vSwitch " "integration bridge ``br-int``." msgstr "" #: ../scenario-classic-ovs.rst:353 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` forwards the packet to the compute " "node via the VLAN interface." msgstr "" #: ../scenario-classic-ovs.rst:362 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` forwards the packet to the compute " "node via the tunnel interface." msgstr "" #: ../scenario-classic-ovs.rst:373 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the actual VLAN tag " "the project network with the internal tag." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:385 ../scenario-classic-ovs.rst:525 #: ../scenario-classic-ovs.rst:612 ../scenario-dvr-ovs.rst:329 #: ../scenario-dvr-ovs.rst:441 ../scenario-provider-ovs.rst:300 #: ../scenario-provider-ovs.rst:366 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "Linux bridge ``qbr``." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:387 ../scenario-provider-ovs.rst:368 msgid "" "Security group rules (4) on the Linux bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-classic-ovs.rst:389 msgid "" "The Linux bridge ``qbr`` forwards the packet to the ``tap`` interface (5) on " "instance 1." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:423 ../scenario-dvr-ovs.rst:395 msgid "Instance 1 resides on compute node 1 and uses project network 1." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:424 ../scenario-dvr-ovs.rst:396 msgid "Instance 2 resides on compute node 2 and uses project network 2." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:430 ../scenario-dvr-ovs.rst:406 #: ../scenario-provider-ovs.rst:266 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the Linux bridge " "``qbr``. The packet contains destination MAC address *TG1* because the " "destination resides on another network." msgstr "" #: ../scenario-classic-ovs.rst:437 msgid "" "The Open vSwitch integration bridge ``br-int`` adds the internal tag for " "project network 1." msgstr "" #: ../scenario-classic-ovs.rst:443 ../scenario-classic-ovs.rst:578 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` replaces the internal tag with the " "actual VLAN tag of project network 1." msgstr "" #: ../scenario-classic-ovs.rst:452 ../scenario-classic-ovs.rst:587 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` wraps the packet in a VXLAN or GRE " "tunnel and adds a tag to identify project network 1." msgstr "" #: ../scenario-classic-ovs.rst:465 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the actual VLAN tag " "of project network 1 with the internal tag." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:472 ../scenario-dvr-ovs.rst:249 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` unwraps the packet and adds the " "internal tag for project network 1." msgstr "" #: ../scenario-classic-ovs.rst:477 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "``qr-1`` interface (3) in the router namespace ``qrouter``. The ``qr-1`` " "interface contains the project network 1 gateway IP address *TG1*." msgstr "" #: ../scenario-classic-ovs.rst:480 msgid "" "The router namespace ``qrouter`` routes the packet to the ``qr-2`` interface " "(4). The ``qr-2`` interface contains the project network 2 gateway IP " "address *TG2*." msgstr "" #: ../scenario-classic-ovs.rst:485 msgid "" "The Open vSwitch integration bridge ``br-int`` adds the internal tag for " "project network 2." msgstr "" #: ../scenario-classic-ovs.rst:491 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` replaces the internal tag with the " "actual VLAN tag of project network 2." msgstr "" #: ../scenario-classic-ovs.rst:493 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` forwards the packet to compute node " "2 via the VLAN interface." msgstr "" #: ../scenario-classic-ovs.rst:500 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` wraps the packet in a VXLAN or GRE " "tunnel and adds a tag to identify project network 2." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:502 ../scenario-dvr-ovs.rst:429 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` forwards the packet to compute " "node 2 via the tunnel interface." msgstr "" #: ../scenario-classic-ovs.rst:513 ../scenario-classic-ovs.rst:600 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the actual VLAN tag " "of project network 2 with the internal tag." msgstr "" #: ../scenario-classic-ovs.rst:520 ../scenario-classic-ovs.rst:607 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` unwraps the packet and adds the " "internal tag for project network 2." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:527 ../scenario-provider-ovs.rst:302 msgid "" "Security group rules (5) on the Linux bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:529 ../scenario-provider-ovs.rst:304 msgid "" "The Linux bridge ``qbr`` forwards the packet to the ``tap`` interface (6) on " "instance 2." msgstr "" #: ../scenario-classic-ovs.rst:559 msgid "Both instances use the same project network." msgstr "" #: ../scenario-classic-ovs.rst:561 msgid "The Open vSwitch agent handles switching within the project network." msgstr "" #: ../scenario-classic-ovs.rst:565 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the VLAN bridge " "``qbr``. The packet contains destination MAC address *I2* because the " "destination resides on the same network." msgstr "" #: ../scenario-classic-ovs.rst:568 msgid "" "Security group rules (2) on the provider bridge ``qbr`` handle state " "tracking for the packet." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:572 ../scenario-provider-ovs.rst:273 msgid "" "The Open vSwitch integration bridge ``br-int`` adds the internal tag for " "provider network 1." msgstr "" #: ../scenario-classic-ovs.rst:580 msgid "" "The Open vSwitch VLAN bridge ``br-vlan`` forwards the packet to the compute " "node 2 via the VLAN interface." msgstr "" #: ../scenario-classic-ovs.rst:589 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` forwards the packet to the compute " "node 2 via the tunnel interface." msgstr "" #: ../scenario-classic-ovs.rst:614 msgid "" "Security group rules (3) on the Linux bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-classic-ovs.rst:616 msgid "" "The Linux bridge ``qbr`` forwards the packet to the ``tap`` interface (4) on " "instance 2." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:670 ../scenario-dvr-ovs.rst:516 #: ../scenario-l3ha-ovs.rst:251 msgid "" "Replace ``MIN_VLAN_ID``, ``MAX_VLAN_ID``, ``MIN_GRE_ID``, ``MAX_GRE_ID``, " "``MIN_VXLAN_ID``, and ``MAX_VXLAN_ID`` with VLAN, GRE, and VXLAN ID minimum " "and maximum values suitable for your environment." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:696 ../scenario-classic-ovs.rst:787 #: ../scenario-dvr-ovs.rst:543 ../scenario-dvr-ovs.rst:637 #: ../scenario-l3ha-ovs.rst:277 ../scenario-l3ha-ovs.rst:369 #: ../scenario-provider-ovs.rst:438 ../scenario-provider-ovs.rst:500 msgid "" "Configure the Open vSwitch agent. Edit the ``/etc/neutron/plugins/ml2/" "openvswitch_agent.ini`` file:" msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:714 ../scenario-classic-ovs.rst:805 #: ../scenario-dvr-ovs.rst:563 ../scenario-dvr-ovs.rst:657 #: ../scenario-l3ha-ovs.rst:295 ../scenario-l3ha-ovs.rst:387 msgid "" "Replace ``TUNNEL_INTERFACE_IP_ADDRESS`` with the IP address of the interface " "that handles GRE/VXLAN project networks." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:742 ../scenario-l3ha-ovs.rst:324 msgid "(Optional) Reduce MTU for VXLAN/GRE project networks." msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:772 ../scenario-classic-ovs.rst:811 #: ../scenario-dvr-ovs.rst:622 ../scenario-dvr-ovs.rst:690 #: ../scenario-l3ha-ovs.rst:354 ../scenario-l3ha-ovs.rst:393 #: ../scenario-provider-ovs.rst:487 ../scenario-provider-ovs.rst:537 msgid "Open vSwitch agent" msgstr "" # #-#-#-#-# scenario-classic-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-classic-ovs.rst:889 ../scenario-l3ha-ovs.rst:475 msgid "" "The example configuration contains ``vlan`` as the first project network " "type. Only an administrative user can create other types of networks such as " "GRE or VXLAN. The following commands use the ``admin`` project credentials " "to create a VXLAN project network." msgstr "" #: ../scenario-dvr-ovs.rst:5 msgid "Scenario: High Availability using Distributed Virtual Routing (DVR)" msgstr "" #: ../scenario-dvr-ovs.rst:7 msgid "" "This scenario describes the high-availability Distributed Virtual Routing " "(DVR) implementation of the OpenStack Networking service using the ML2 plug-" "in and Open vSwitch. The example configuration creates one flat external " "network and one VXLAN project (tenant) network. However, this configuration " "also supports VLAN external networks, VLAN project networks, and GRE project " "networks." msgstr "" #: ../scenario-dvr-ovs.rst:14 msgid "" "The DVR architecture augments the classic architecture by providing direct " "connectivity to external networks on compute nodes. For instances with a " "floating IP address, routing between project and external networks resides " "completely on the compute nodes to eliminate single point of failure and " "performance issues with classic network nodes. Routing also resides " "completely on the compute nodes for instances with a fixed or floating IP " "address using project networks on the same distributed virtual router. " "However, instances with a fixed IP address still rely on the network node " "for routing and SNAT services between project and external networks." msgstr "" #: ../scenario-dvr-ovs.rst:41 msgid "" "One network node with four network interfaces: management, project tunnel " "networks, VLAN project networks, and external (typically the Internet). The " "Open vSwitch bridge ``br-vlan`` must contain a port on the VLAN interface " "and the Open vSwitch bridge ``br-ex`` must contain a port on the external " "interface." msgstr "" #: ../scenario-dvr-ovs.rst:46 msgid "" "At least two compute nodes with four network interfaces: management, project " "tunnel networks, project VLAN networks, and external (typically the " "Internet). The Open vSwitch bridge ``br-vlan`` must contain a port on the " "VLAN interface and the Open vSwitch bridge ``br-ex`` must contain a port on " "the external interface." msgstr "" #: ../scenario-dvr-ovs.rst:52 msgid "" "In the example configuration, the management network uses 10.0.0.0/24, the " "tunnel network uses 10.0.1.0/24, and the external network uses " "203.0.113.0/24. The VLAN network does not require an IP address range " "because it only handles layer 2 connectivity." msgstr "" # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-dvr-ovs.rst:67 ../scenario-l3ha-ovs.rst:82 msgid "" "For VLAN external and project networks, the network infrastructure must " "support VLAN tagging. For best performance with VXLAN and GRE project " "networks, the network infrastructure should support jumbo frames." msgstr "" # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-dvr-ovs.rst:110 ../scenario-l3ha-lb.rst:118 msgid "" "Operational OpenStack Compute hypervisor service with appropriate " "configuration to use neutron in the ``nova.conf`` file." msgstr "" #: ../scenario-dvr-ovs.rst:112 msgid "" "Open vSwitch service, Open vSwitch agent, L3 agent, metadata agent, and any " "dependencies." msgstr "" #: ../scenario-dvr-ovs.rst:122 msgid "" "The term *north-south* generally defines network traffic that travels " "between an instance and external network (typically the Internet) and the " "term *east-west* generally defines network traffic that travels between " "instances." msgstr "" #: ../scenario-dvr-ovs.rst:132 msgid "" "DHCP agent managing the ``qdhcp`` namespaces. The ``dhcp`` namespaces " "provide DHCP services for instances using project networks." msgstr "" #: ../scenario-dvr-ovs.rst:134 msgid "L3 agent managing the ``qrouter`` and ``snat`` namespaces." msgstr "" #: ../scenario-dvr-ovs.rst:136 msgid "" "For instances using project networks on classic routers, the ``qrouter`` " "namespaces route *north-south* and *east-west* network traffic and perform " "DNAT/SNAT similar to the classic scenarios. They also route metadata traffic " "between instances and the metadata agent." msgstr "" #: ../scenario-dvr-ovs.rst:140 msgid "" "For instances with a fixed IP address using project networks on distributed " "routers, the ``snat`` namespaces perform SNAT for *north-south* network " "traffic." msgstr "" #: ../scenario-dvr-ovs.rst:144 msgid "" "Metadata agent handling metadata operations for instances using project " "networks on classic routers." msgstr "" #: ../scenario-dvr-ovs.rst:159 msgid "L3 agent managing the ``qrouter`` and ``fip`` namespaces." msgstr "" #: ../scenario-dvr-ovs.rst:161 msgid "" "For instances with a floating IP address using project networks on " "distributed routers, the ``fip`` namespaces route *north-south* network " "traffic and perform DNAT/SNAT." msgstr "" #: ../scenario-dvr-ovs.rst:164 msgid "" "For instances with a fixed or floating IP address using project networks on " "distributed routers, the ``qrouter`` namespaces route *east-west* traffic." msgstr "" #: ../scenario-dvr-ovs.rst:168 msgid "" "Metadata agent handling metadata operations for instances using project " "networks on distributed routers." msgstr "" # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-dvr-ovs.rst:170 ../scenario-l3ha-ovs.rst:161 #: ../scenario-provider-ovs.rst:146 msgid "Linux bridges handling security groups." msgstr "" # #-#-#-#-# scenario-dvr-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-dvr-ovs.rst:173 ../scenario-l3ha-ovs.rst:164 #: ../scenario-provider-ovs.rst:149 msgid "" "Due to limitations with Open vSwitch and *iptables*, the Networking service " "uses a Linux bridge to manage security groups for instances." msgstr "" #: ../scenario-dvr-ovs.rst:187 msgid "Case 1: North/south for instances with a fixed IP address" msgstr "" #: ../scenario-dvr-ovs.rst:189 msgid "" "For instances with a fixed IP address using project networks on distributed " "routers, the network node routes *north-south* network traffic between " "project and external networks." msgstr "" #: ../scenario-dvr-ovs.rst:196 ../scenario-dvr-ovs.rst:283 msgid "Gateway 203.0.113.1 with MAC address *EG*" msgstr "" #: ../scenario-dvr-ovs.rst:197 ../scenario-dvr-ovs.rst:284 msgid "Floating IP range 203.0.113.101 to 203.0.113.200" msgstr "" #: ../scenario-dvr-ovs.rst:199 msgid "Project network SNAT interface 192.168.1.2 with MAC address *TN*" msgstr "" #: ../scenario-dvr-ovs.rst:209 ../scenario-dvr-ovs.rst:296 #: ../scenario-dvr-ovs.rst:388 msgid "DVR MAC address *D1*" msgstr "" #: ../scenario-dvr-ovs.rst:214 ../scenario-dvr-ovs.rst:302 #: ../scenario-dvr-ovs.rst:400 msgid "" "This scenario supports both VLAN and GRE/VXLAN project networks. However, " "the packet flow only considers one instance using a VXLAN project network " "for simplicity." msgstr "" #: ../scenario-dvr-ovs.rst:227 msgid "" "The Open vSwitch integration bridge ``br-int`` modifies the packet to " "contain the internal tag for project network 1." msgstr "" #: ../scenario-dvr-ovs.rst:229 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet (3) to " "the project network 1 gateway *TG* interface ``qr`` in the distributed " "router namespace ``qrouter``." msgstr "" #: ../scenario-dvr-ovs.rst:232 msgid "" "The distributed router ``qrouter`` namespace resolves the project network 1 " "SNAT interface MAC address *TN* on the ``sg`` interface (4) in the SNAT " "namespace ``snat`` and forwards the packet to the Open vSwitch integration " "bridge ``br-int``." msgstr "" #: ../scenario-dvr-ovs.rst:238 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` replaces the packet source MAC " "address *I1* with *D1*." msgstr "" #: ../scenario-dvr-ovs.rst:240 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` wraps the packet in a VXLAN tunnel " "that contains a tag for project network 1." msgstr "" #: ../scenario-dvr-ovs.rst:253 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the packet source " "MAC address *D1* with *TG*." msgstr "" #: ../scenario-dvr-ovs.rst:255 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "``sg`` interface (4) in the SNAT namespace ``snat``." msgstr "" #: ../scenario-dvr-ovs.rst:257 msgid "" "The *iptables* service (5) performs SNAT on the packet using the project " "network 1 router interface IP address *TR* on the ``qg`` interface (6)." msgstr "" #: ../scenario-dvr-ovs.rst:259 msgid "" "The ``qg`` interface forwards the packet to the Open vSwitch external bridge " "``br-ex``." msgstr "" #: ../scenario-dvr-ovs.rst:271 msgid "Case 2: North/south for instances with a floating IP address" msgstr "" #: ../scenario-dvr-ovs.rst:273 msgid "" "For instances with a floating IP address using project networks on " "distributed routers, the compute node containing the instance routes *north-" "south* network traffic between project and external networks, avoiding the " "network node. Given the complexity of this case, the following case covers " "both the flow of network traffic from the external network to an instance " "and from an instance to the external network." msgstr "" #: ../scenario-dvr-ovs.rst:292 msgid "Compute node" msgstr "" #: ../scenario-dvr-ovs.rst:297 msgid "DVR internal IP addresses *DA1* and *DA2*" msgstr "" #: ../scenario-dvr-ovs.rst:300 msgid "Instance 1 sends a packet to a host on the external network." msgstr "" #: ../scenario-dvr-ovs.rst:306 msgid "" "The following steps involve a packet inbound from the external network to an " "instance on compute node 1:" msgstr "" #: ../scenario-dvr-ovs.rst:309 msgid "" "The external interface forwards the packet to the Open vSwitch external " "bridge ``br-ex``. The packet contains destination IP address *F1*." msgstr "" #: ../scenario-dvr-ovs.rst:312 msgid "" "The Open vSwitch external bridge ``br-ex`` forwards the packet to the ``fg`` " "interface (1) in the floating IP namespace ``fip``. The ``fg`` interface " "responds to any ARP requests for the instance floating IP address *F1*." msgstr "" #: ../scenario-dvr-ovs.rst:316 msgid "" "The floating IP namespace ``fip`` routes the packet (2) to the distributed " "router namespace ``qrouter`` using DVR internal IP addresses *DA1* and " "*DA2*. The ``fpr`` interface (3) contains DVR internal IP address *DA1* and " "the ``rfp`` interface (4) contains DVR internal IP address *DA2*." msgstr "" #: ../scenario-dvr-ovs.rst:321 msgid "" "The floating IP namespace ``fip`` forwards the packet to the ``rfp`` " "interface (5) in the distributed router namespace ``qrouter``. The ``rfp`` " "interface also contains the instance floating IP address *F1*." msgstr "" #: ../scenario-dvr-ovs.rst:324 msgid "" "The *iptables* service (6) in the distributed router namespace ``qrouter`` " "performs DNAT on the packet using the destination IP address. The ``qr`` " "interface (7) contains the project network gateway IP address *TG*." msgstr "" #: ../scenario-dvr-ovs.rst:327 msgid "" "The distributed router namespace ``qrouter`` forwards the packet to the Open " "vSwitch integration bridge ``br-int``." msgstr "" #: ../scenario-dvr-ovs.rst:331 msgid "" "Security group rules (8) on the Linux bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-dvr-ovs.rst:333 msgid "" "The Linux bridge ``qbr`` forwards the packet to the instance ``tap`` " "interface (9)." msgstr "" #: ../scenario-dvr-ovs.rst:336 msgid "" "The following steps involve a packet outbound from an instance on compute " "node 1 to the external network:" msgstr "" #: ../scenario-dvr-ovs.rst:339 msgid "" "The instance 1 ``tap`` interface (9) forwards the packet to the Linux bridge " "``qbr``. The packet contains destination MAC address *TG1* because the " "destination resides on another network." msgstr "" #: ../scenario-dvr-ovs.rst:342 msgid "" "Security group rules (8) on the Linux bridge ``qbr`` handle state tracking " "for the packet." msgstr "" #: ../scenario-dvr-ovs.rst:346 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "``qr`` interface (7) in the distributed router namespace ``qrouter``. The " "``qr`` interface contains the project network gateway IP address *TG*." msgstr "" #: ../scenario-dvr-ovs.rst:350 msgid "" "The *iptables* service (6) performs SNAT on the packet using the ``rfp`` " "interface (5) as the source IP address. The ``rfp`` interface contains the " "instance floating IP address *F1*." msgstr "" #: ../scenario-dvr-ovs.rst:353 msgid "" "The distributed router namespace ``qrouter`` (2) routes the packet to the " "floating IP namespace ``fip`` using DVR internal IP addresses *DA1* and " "*DA2*. The ``rfp`` interface (4) contains DVR internal IP address *DA2* and " "the ``fpr`` interface (3) contains DVR internal IP address *DA1*." msgstr "" #: ../scenario-dvr-ovs.rst:358 msgid "" "The ``fg`` interface (1) in the floating IP namespace ``fip`` forwards the " "packet to the Open vSwitch external bridge ``br-ex``. The ``fg`` interface " "contains the project router external IP address *TE*." msgstr "" #: ../scenario-dvr-ovs.rst:368 msgid "" "Case 3: East/west for instances using different networks on the same router" msgstr "" #: ../scenario-dvr-ovs.rst:370 msgid "" "For instances with fixed or floating IP addresses using project networks on " "distributed routers, the compute nodes route *east-west* network traffic " "among the project networks that reside on the same distributed virtual " "router, avoiding the network node." msgstr "" #: ../scenario-dvr-ovs.rst:378 msgid "Gateway 192.168.1.1 with MAC address *TG1*" msgstr "" #: ../scenario-dvr-ovs.rst:382 msgid "Network 192.168.2.0/24" msgstr "" #: ../scenario-dvr-ovs.rst:383 msgid "Gateway 192.168.2.1 with MAC address *TG2*" msgstr "" #: ../scenario-dvr-ovs.rst:392 msgid "Instance 2 192.168.2.11 with MAC address *I2*" msgstr "" #: ../scenario-dvr-ovs.rst:393 msgid "DVR MAC address *D2*" msgstr "" #: ../scenario-dvr-ovs.rst:397 msgid "Both project networks reside on the same distributed virtual router." msgstr "" #: ../scenario-dvr-ovs.rst:413 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "project network 1 interface (3) in the distributed router namespace " "``qrouter``." msgstr "" #: ../scenario-dvr-ovs.rst:416 msgid "" "The distributed router namespace ``qrouter`` routes the packet to project " "network 2." msgstr "" #: ../scenario-dvr-ovs.rst:418 msgid "" "The project network 2 interface (4) in the distributed router namespace " "``qrouter`` namespace forwards the packet to the Open vSwitch integration " "bridge ``br-int``." msgstr "" #: ../scenario-dvr-ovs.rst:421 msgid "" "The Open vSwitch integration bridge ``br-int`` modifies the packet to " "contain the internal tag for project network 2." msgstr "" #: ../scenario-dvr-ovs.rst:425 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` replaces the packet source MAC " "address *TG2* with *D1*." msgstr "" #: ../scenario-dvr-ovs.rst:427 msgid "" "The Open vSwitch tunnel bridge ``br-tun`` wraps the packet in a VXLAN tunnel " "that contains a tag for project network 2." msgstr "" #: ../scenario-dvr-ovs.rst:436 msgid "The Open vSwitch tunnel bridge ``br-tun`` unwraps the packet." msgstr "" #: ../scenario-dvr-ovs.rst:439 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the packet source " "MAC address *D1* with *TG2*." msgstr "" #: ../scenario-dvr-ovs.rst:443 msgid "" "Security group rules (7) on the Linux bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-dvr-ovs.rst:445 msgid "" "The Linux bridge ``qbr`` forwards the packet to the instance 2 ``tap`` " "interface (8)." msgstr "" #: ../scenario-dvr-ovs.rst:449 msgid "" "Packets arriving from compute node 1 do not traverse the project network " "interfaces (5,6) in the ``qrouter`` namespace on compute node 2. However, " "return traffic traverses them." msgstr "" #: ../scenario-dvr-ovs.rst:468 msgid "This configuration primarily supports the Kilo release." msgstr "" #: ../scenario-dvr-ovs.rst:485 msgid "" "Configuring the ``router_distributed = True`` option creates distributed " "routers by default for all users. Without it, only privileged users can " "create distributed routers using the ``--distributed True`` option during " "router creation." msgstr "" #: ../scenario-dvr-ovs.rst:521 msgid "" "The first value in the ``tenant_network_types`` option becomes the default " "project network type when a non-privileged user creates a network." msgstr "" #: ../scenario-dvr-ovs.rst:526 msgid "" "The ``external`` value in the ``network_vlan_ranges`` option lacks VLAN ID " "ranges to support use of arbitrary VLAN IDs by privileged users." msgstr "" #: ../scenario-dvr-ovs.rst:592 msgid "(Optional) Reduce MTU for GRE/VXLAN project networks." msgstr "" #: ../scenario-dvr-ovs.rst:774 msgid "" "The example configuration contains ``vlan`` as the first project network " "type. Only a privileged user can create other types of networks such as GRE " "or VXLAN. The following commands use the ``admin`` project credentials to " "create a VXLAN project network." msgstr "" #: ../scenario-dvr-ovs.rst:816 ../scenario-dvr-ovs.rst:928 msgid "Source the regular project credentials." msgstr "" #: ../scenario-dvr-ovs.rst:842 msgid "Create a distributed project router:" msgstr "" #: ../scenario-dvr-ovs.rst:863 msgid "" "Default policy might prevent the '`distributed`` flag from appearing in the " "command output for non-privileged users." msgstr "" #: ../scenario-dvr-ovs.rst:866 msgid "Attach the project network to the router:" msgstr "" #: ../scenario-dvr-ovs.rst:873 msgid "" "Add a gateway to the external network for the project network on the router:" msgstr "" #: ../scenario-dvr-ovs.rst:884 msgid "" "On the network node, verify creation of the `snat`, `qrouter`, and `qdhcp` " "namespaces:" msgstr "" #: ../scenario-dvr-ovs.rst:895 msgid "One or more namespaces might not exist until launching an instance." msgstr "" #: ../scenario-dvr-ovs.rst:930 msgid "" "On the compute node with the instance, verify creation of the ``qrouter`` " "namespace:" msgstr "" #: ../scenario-dvr-ovs.rst:1025 msgid "" "On the compute node with the instance, verify creation of the ``fip`` " "namespace:" msgstr "" #: ../scenario-l3ha-lb.rst:5 msgid "Scenario: High Availability using VRRP (L3HA) with Linux Bridge" msgstr "" #: ../scenario-l3ha-lb.rst:7 msgid "" "This scenario describes a high-availability implementation of the OpenStack " "Networking service using the ML2 plug-in and Linux bridge." msgstr "" #: ../scenario-l3ha-lb.rst:10 msgid "" "This high-availability implementation augments the :ref:`scenario-classic-" "lb` architecture with Virtual Router Redundancy Protocol (VRRP) using " "``keepalived`` to provide quick failover of layer-3 services. See :ref:" "`scenario_l3ha_lb-packet_flow` for VRRP operation. Similar to the classic " "scenario, all network traffic on a project network that requires routing " "actively traverses only one network node regardless of the quantity of " "network nodes providing HA for the router. Therefore, this high-availability " "implementation primarily addresses failure situations instead of bandwidth " "constraints that limit performance. However, it supports random distribution " "of routers on different network nodes to reduce the chances of bandwidth " "constraints and to improve scaling. Also, this implementation does not " "address situations where one or more layer-3 agents fail and the underlying " "virtual networks continue to operate normally. Consider deploying :ref:" "`scenario-dvr-ovs` to increase performance in addition to redundancy. As of " "the Liberty release, you cannot combine the DVR and L3HA mechanisms." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:27 ../scenario-l3ha-ovs.rst:27 msgid "" "The failover process only retains the state of network connections for " "instances with a floating IP address." msgstr "" #: ../scenario-l3ha-lb.rst:30 msgid "" "The example configuration creates one flat external network and one VXLAN " "project (tenant) network. However, this configuration also supports VLAN " "external and project networks." msgstr "" #: ../scenario-l3ha-lb.rst:36 msgid "" "Due to a bug, we recommend disabling the layer-2 population mechanism for " "deployments using VXLAN project networks. For more information, see " "``__." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:43 ../scenario-l3ha-ovs.rst:37 msgid "" "These prerequisites define the minimal physical infrastructure and immediate " "OpenStack service dependencies necessary to deploy this scenario. For " "example, the Networking service immediately depends on the Identity service " "and the Compute service immediately depends on the Networking service. These " "dependencies lack services such as the Image service because the Networking " "service does not immediately depend on it. However, the Compute service " "depends on the Image service to launch an instance. The example " "configuration in this scenario assumes basic configuration knowledge of " "Networking service components. For assistance with basic configuration of " "the Networking service, see the Installation Guide." msgstr "" #: ../scenario-l3ha-lb.rst:58 msgid "" "At least two network nodes with four network interfaces: management, project " "tunnel networks, project VLAN networks, and external (typically the " "Internet)." msgstr "" #: ../scenario-l3ha-lb.rst:61 msgid "" "At least two compute nodes with three network interfaces: management, " "project tunnel networks, and project VLAN networks." msgstr "" #: ../scenario-l3ha-lb.rst:64 msgid "" "To improve understanding of network traffic flow, the network and compute " "nodes contain a separate network interface for project VLAN networks. In " "production environments, you can use any network interface for VLAN project " "networks." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:69 ../scenario-l3ha-ovs.rst:67 msgid "" "In the example configuration, the management network uses 10.0.0.0/24, the " "tunnel network uses 10.0.1.0/24, the VRRP network uses 169.254.192.0/18, and " "the external network uses 203.0.113.0/24. The VLAN network does not require " "an IP address range because it only handles layer-2 connectivity." msgstr "" #: ../scenario-l3ha-lb.rst:84 msgid "" "For VLAN external and project networks, the network infrastructure must " "support VLAN tagging. For best performance with VXLAN project networks, the " "network infrastructure should support jumbo frames." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:106 ../scenario-l3ha-ovs.rst:114 msgid "OpenStack services - network nodes" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:128 ../scenario-l3ha-ovs.rst:137 msgid "The network nodes contain the following components:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:135 ../scenario-l3ha-ovs.rst:144 msgid "" "L3 agent managing the ``qrouter`` namespaces and VRRP using ``keepalived``. " "The ``qrouter`` namespaces provide routing between project and external " "networks and among project networks. They also route metadata traffic " "between instances and the metadata agent." msgstr "" #: ../scenario-l3ha-lb.rst:148 msgid "" "For simplicity, the hidden project network that connects all HA routers for " "a particular project uses the VXLAN network type." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:153 ../scenario-provider-lb.rst:137 msgid "" "Linux bridge agent managing virtual switches, connectivity among them, and " "interaction via virtual ports with other network components such as " "namespaces, security groups, and underlying interfaces." msgstr "" #: ../scenario-l3ha-lb.rst:168 msgid "" "The L3HA mechanism simply augments :ref:`scenario-classic-lb` with quick " "failover of layer-3 services to another router if the master router fails." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:172 ../scenario-l3ha-ovs.rst:183 msgid "" "During normal operation, the master router periodically transmits " "*heartbeat* packets over a hidden project network that connects all HA " "routers for a particular project. By default, this network uses the type " "indicated by the first value in the ``tenant_network_types`` option in the :" "file:`/etc/neutron/plugins/ml2_conf.ini` file." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:178 ../scenario-l3ha-ovs.rst:189 msgid "" "If the backup router stops receiving these packets, it assumes failure of " "the master router and promotes itself to the master router by configuring IP " "addresses on the interfaces in the ``qrouter`` namespace. In environments " "with more than one backup router, the router with the next highest priority " "becomes the master router." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:185 ../scenario-l3ha-ovs.rst:196 msgid "" "The L3HA mechanism uses the same priority for all routers. Therefore, VRRP " "promotes the backup router with the highest IP address to the master router." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:254 ../scenario-l3ha-ovs.rst:268 msgid "Network nodes" msgstr "" #: ../scenario-l3ha-lb.rst:486 msgid "Create a project network:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:558 ../scenario-l3ha-ovs.rst:566 msgid "" "The default :file:`policy.json` file allows only administrative projects to " "enable/disable HA during router creation and view the ``ha`` flag for a " "router." msgstr "" #: ../scenario-l3ha-lb.rst:562 msgid "Attach the project subnet as an interface on the router:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:580 ../scenario-l3ha-ovs.rst:588 msgid "On the controller node, verify creation of the HA network:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:593 ../scenario-l3ha-ovs.rst:601 msgid "" "On the controller node, verify creation of the router on more than one " "network node:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:607 ../scenario-l3ha-ovs.rst:615 msgid "" "Older versions of *python-neutronclient* do not support the ``ha_state`` " "field." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:609 ../scenario-l3ha-ovs.rst:617 msgid "" "On the controller node, verify creation of the HA ports on the ``demo-" "router`` router:" msgstr "" #: ../scenario-l3ha-lb.rst:624 msgid "" "On the network nodes, verify creation of the ``qrouter`` and ``qdhcp`` " "namespaces." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:627 ../scenario-l3ha-lb.rst:649 #: ../scenario-l3ha-lb.rst:704 ../scenario-l3ha-ovs.rst:635 #: ../scenario-l3ha-ovs.rst:656 ../scenario-l3ha-ovs.rst:711 msgid "Network node 1:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:634 ../scenario-l3ha-lb.rst:673 #: ../scenario-l3ha-lb.rst:713 ../scenario-l3ha-ovs.rst:642 #: ../scenario-l3ha-ovs.rst:680 ../scenario-l3ha-ovs.rst:720 msgid "Network node 2:" msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:641 ../scenario-l3ha-ovs.rst:649 msgid "Both ``qrouter`` namespaces should use the same UUID." msgstr "" #: ../scenario-l3ha-lb.rst:645 msgid "The ``qdhcp`` namespaces might not appear until launching an instance." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:647 ../scenario-l3ha-ovs.rst:654 msgid "On the network nodes, verify HA operation:" msgstr "" #: ../scenario-l3ha-lb.rst:693 msgid "" "On each network node, the ``qrouter`` namespace should include the ``ha``, " "``qr``, and ``qg`` interfaces. On the master node, the ``qr`` interface " "contains the project network gateway IP address and the ``qg`` interface " "contains the project network router IP address on the external network. On " "the backup node, the ``qr`` and ``qg`` interfaces should not contain an IP " "address. On both nodes, the ``ha`` interface should contain a unique IP " "address in the 169.254.192.0/18 range." msgstr "" #: ../scenario-l3ha-lb.rst:701 msgid "" "On the network nodes, verify VRRP advertisements from the master node HA " "interface IP address on the appropriate network interface." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:724 ../scenario-l3ha-ovs.rst:730 msgid "The example output uses network interface ``eth1``." msgstr "" #: ../scenario-l3ha-lb.rst:758 msgid "" "Source the credentials for a non-privileged project. The following steps use " "the ``demo`` project." msgstr "" # #-#-#-#-# scenario-l3ha-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-l3ha-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-l3ha-lb.rst:779 ../scenario-l3ha-ovs.rst:785 msgid "" "Launch an instance with an interface on the project network. For example, " "using an existing *CirrOS* image:" msgstr "" #: ../scenario-l3ha-ovs.rst:5 msgid "Scenario: High Availability using VRRP (L3HA) with Open vSwitch" msgstr "" #: ../scenario-l3ha-ovs.rst:7 msgid "" "This scenario describes a high-availability implementation of the OpenStack " "Networking service using the ML2 plug-in and Open vSwitch (OVS)." msgstr "" #: ../scenario-l3ha-ovs.rst:10 msgid "" "This high-availability implementation augments the :ref:`scenario-classic-" "ovs` architecture with Virtual Router Redundancy Protocol (VRRP) using " "``keepalived`` to provide quick failover of layer-3 services. See :ref:" "`scenario_l3ha_ovs-packet_flow` for VRRP operation. Similar to the classic " "scenario, all network traffic on a project network that requires routing " "actively traverses only one network node regardless of the quantity of " "network nodes providing HA for the router. Therefore, this high-availability " "implementation primarily addresses failure situations instead of bandwidth " "constraints that limit performance. However, it supports random distribution " "of routers on different network nodes to reduce the chances of bandwidth " "constraints and to improve scaling. Also, this implementation does not " "address situations where one or more layer-3 agents fail and the underlying " "virtual networks continue to operate normally. Consider deploying ref:" "`scenario-dvr-ovs` to increase performance in addition to redundancy. As of " "the Liberty release, you cannot combine the DVR and L3HA mechanisms." msgstr "" #: ../scenario-l3ha-ovs.rst:52 msgid "" "Two network nodes with four network interfaces: management, project tunnel " "networks, project VLAN networks, and external (typically the Internet). The " "Open vSwitch bridge ``br-vlan`` must contain a port on the VLAN interface " "and Open vSwitch bridge ``br-ex`` must contain a port on the external " "interface." msgstr "" #: ../scenario-l3ha-ovs.rst:57 msgid "" "At least one compute node with three network interfaces: management, project " "tunnel networks, and project VLAN networks. The Open vSwitch bridge ``br-" "vlan`` must contain a port on the VLAN interface." msgstr "" #: ../scenario-l3ha-ovs.rst:61 msgid "" "To improve understanding of network traffic flow, the network and compute " "nodes contain a separate network interface for project VLAN networks. In " "production environments, project VLAN networks can use any Open vSwitch " "bridge with access to a network interface. For example, the ``br-tun`` " "bridge." msgstr "" #: ../scenario-l3ha-ovs.rst:108 msgid "" "Operational OpenStack Compute controller/management service with appropriate " "configuration to use OpenStack Networking in the :file:`nova.conf` file." msgstr "" #: ../scenario-l3ha-ovs.rst:126 msgid "" "Operational OpenStack Compute controller/management service with appropriate " "configuration to use OpenStack Networking in the ``neutron.conf`` file." msgstr "" #: ../scenario-l3ha-ovs.rst:156 msgid "The compute nodes contain the following components:" msgstr "" #: ../scenario-l3ha-ovs.rst:179 msgid "" "The L3HA mechanism simply augments :ref:`scenario-classic-ovs` with quick " "failover of layer-3 services to another router if the master router fails." msgstr "" #: ../scenario-l3ha-ovs.rst:518 msgid "" "Source the ``demo`` project credentials. The following steps use the " "``demo`` project." msgstr "" #: ../scenario-l3ha-ovs.rst:632 msgid "" "On the network nodes, verify creation of the ``qrouter`` and ``qdhcp`` " "namespaces:" msgstr "" #: ../scenario-l3ha-ovs.rst:652 msgid "The ``qdhcp`` namespaces might not exist until launching an instance." msgstr "" #: ../scenario-l3ha-ovs.rst:700 msgid "" "On each network node, the ``qrouter`` namespace should include the ``ha``, " "``qr``, and ``qg`` interfaces. On the master node, the ``qr`` interface " "contains the project network gateway IP address and the ``qg`` interface " "contains the project router IP address on the external network. On the " "backup node, the ``qr`` and ``qg`` interfaces should not contain an IP " "address. On both nodes, the ``ha`` interface should contain a unique IP " "address in the 169.254.192.0/18 range." msgstr "" #: ../scenario-l3ha-ovs.rst:708 msgid "" "On the network nodes, verify VRRP advertisements from the master node HA " "interface IP address on the appropriate network interface:" msgstr "" #: ../scenario-provider-lb.rst:5 msgid "Scenario: Provider networks with Linux bridge" msgstr "" #: ../scenario-provider-lb.rst:7 msgid "" "This scenario describes a provider networks implementation of the OpenStack " "Networking service using the ML2 plug-in with Linux bridge." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:10 ../scenario-provider-ovs.rst:10 msgid "" "Provider networks generally offer simplicity, performance, and reliability " "at the cost of flexibility. Unlike other scenarios, only administrators can " "manage provider networks because they require configuration of physical " "network infrastructure. Also, provider networks lack the concept of fixed " "and floating IP addresses because they only handle layer-2 connectivity for " "instances." msgstr "" #: ../scenario-provider-lb.rst:17 msgid "" "In many cases, operators who are already familiar with virtual networking " "architectures that rely on physical network infrastructure for layer-2, " "layer-3, or other services can seamlessly deploy the OpenStack Networking " "service. In particular, this scenario appeals to operators looking to " "migrate from the Compute networking service (nova-net) to the OpenStack " "Networking service. Over time, operators can build on this minimal " "deployment to enable more cloud networking features." msgstr "" #: ../scenario-provider-lb.rst:25 msgid "" "Before OpenStack Networking introduced Distributed Virtual Routers (DVR), " "all network traffic traversed one or more dedicated network nodes which " "limited performance and reliability. Physical network infrastructures " "typically offer better performance and reliability than general-purpose " "hosts that handle various network operations in software." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:31 ../scenario-provider-ovs.rst:28 msgid "" "In general, the OpenStack Networking software components that handle layer-3 " "operations impact performance and reliability the most. To improve " "performance and reliability, provider networks move layer-3 operations to " "the physical network infrastructure." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:36 ../scenario-provider-ovs.rst:33 msgid "" "In one particular use case, the OpenStack deployment resides in a mixed " "environment with conventional virtualization and bare-metal hosts that use a " "sizable physical network infrastructure. Applications that run inside the " "OpenStack deployment might require direct layer-2 access, typically using " "VLANs, to applications outside of the deployment." msgstr "" #: ../scenario-provider-lb.rst:42 msgid "" "In comparison to provider networks with Open vSwitch (OVS), this scenario " "relies completely on native Linux networking services which makes it the " "simplest of all scenarios in this guide." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:46 ../scenario-provider-ovs.rst:39 msgid "" "The example configuration creates a VLAN provider network. However, it also " "supports flat (untagged or native) provider networks." msgstr "" #: ../scenario-provider-lb.rst:52 msgid "" "These prerequisites define the minimum physical infrastructure and OpenStack " "service dependencies that you need to deploy this scenario. For example, the " "Networking service immediately depends on the Identity service, and the " "Compute service immediately depends on the Networking service. These " "dependencies lack services such as the Image service because the Networking " "service does not immediately depend on it. However, the Compute service " "depends on the Image service to launch an instance. The example " "configuration in this scenario assumes basic configuration knowledge of " "Networking service components." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:61 ../scenario-provider-ovs.rst:54 msgid "" "For illustration purposes, the management network uses 10.0.0.0/24 and " "provider networks use 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24." msgstr "" #: ../scenario-provider-lb.rst:67 msgid "" "One controller node with two network interfaces: management and provider. " "The provider interface connects to a generic network that physical network " "infrastructure switches/routes to external networks (typically the Internet)." msgstr "" #: ../scenario-provider-lb.rst:71 msgid "" "At least two compute nodes with two network interfaces: management and " "provider. The provider interface connects to a generic network that physical " "network infrastructure switches/routes to external networks (typically the " "Internet)." msgstr "" #: ../scenario-provider-lb.rst:96 msgid "" "Neutron server service, ML2 plug-in, Linux bridge agent, DHCP agent, and any " "dependencies." msgstr "" #: ../scenario-provider-lb.rst:106 msgid "ML2 plug-in, Linux bridge agent, and any dependencies." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:111 ../scenario-provider-ovs.rst:117 msgid "" "The general provider network architecture uses physical network " "infrastructure to handle switching and routing of network traffic." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:117 ../scenario-provider-ovs.rst:123 msgid "The controller node contains the following network components:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:122 ../scenario-provider-ovs.rst:128 msgid "" "DHCP agent managing the ``qdhcp`` namespaces. The ``qdhcp`` namespaces " "provide DHCP services for instances using provider networks." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:132 ../scenario-provider-lb.rst:148 #: ../scenario-provider-ovs.rst:138 ../scenario-provider-ovs.rst:159 msgid "" "For illustration purposes, the diagram contains two different provider " "networks." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:160 ../scenario-provider-ovs.rst:176 msgid "Case 1: North-south" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:162 ../scenario-provider-ovs.rst:178 msgid "" "The physical network infrastructure handles routing and potentially other " "services between the provider and external network. In this case, *provider* " "and *external* simply differentiate between a network available to instances " "and a network only accessible via router, respectively, to illustrate that " "the physical network infrastructure handles routing. However, provider " "networks support direct connection to *external* networks such as the " "Internet." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:174 ../scenario-provider-ovs.rst:190 msgid "Provider network (VLAN)" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:176 ../scenario-provider-ovs.rst:192 msgid "Network 192.0.2.0/24" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:177 ../scenario-provider-ovs.rst:193 msgid "Gateway 192.0.2.1 with MAC address *TG*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:181 ../scenario-provider-ovs.rst:197 msgid "Instance 1 192.0.2.11 with MAC address *I1*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:183 ../scenario-provider-ovs.rst:199 msgid "Instance 1 resides on compute node 1 and uses a provider network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:186 ../scenario-provider-ovs.rst:202 msgid "The following steps involve compute node 1." msgstr "" #: ../scenario-provider-lb.rst:188 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the provider " "bridge ``qbr``. The packet contains destination MAC address *TG* because the " "destination resides on another network." msgstr "" #: ../scenario-provider-lb.rst:191 msgid "" "Security group rules (2) on the provider bridge ``qbr`` handle firewalling " "and tracking for the packet." msgstr "" #: ../scenario-provider-lb.rst:193 ../scenario-provider-lb.rst:251 #: ../scenario-provider-lb.rst:316 msgid "" "The provider bridge ``qbr`` forwards the packet to the logical VLAN " "interface ``device.sid`` where *device* references the underlying physical " "provider interface and *sid* contains the provider network segmentation ID." msgstr "" #: ../scenario-provider-lb.rst:197 msgid "" "The logical VLAN interface ``device.sid`` forwards the packet to the " "physical network via the physical provider interface." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:200 ../scenario-provider-lb.rst:258 #: ../scenario-provider-lb.rst:323 ../scenario-provider-ovs.rst:220 #: ../scenario-provider-ovs.rst:282 ../scenario-provider-ovs.rst:354 msgid "The following steps involve the physical network infrastructure:" msgstr "" #: ../scenario-provider-lb.rst:202 msgid "" "A switch (3) handles any VLAN tag operations between the provider network " "and the router (4)." msgstr "" #: ../scenario-provider-lb.rst:204 msgid "" "A router (4) routes the packet from the provider network to the external " "network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:206 ../scenario-provider-ovs.rst:226 msgid "" "A switch (3) handles any VLAN tag operations between the router (4) and the " "external network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:208 ../scenario-provider-ovs.rst:228 msgid "A switch (3) forwards the packet to the external network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:217 ../scenario-provider-ovs.rst:237 msgid "Case 2: East-west for instances on different networks" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:219 ../scenario-provider-ovs.rst:239 msgid "" "The physical network infrastructure handles routing between the provider " "networks." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:222 ../scenario-provider-ovs.rst:242 msgid "Provider network 1" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:224 ../scenario-provider-lb.rst:294 #: ../scenario-provider-ovs.rst:244 ../scenario-provider-ovs.rst:321 msgid "Network: 192.0.2.0/24" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:225 ../scenario-provider-ovs.rst:245 msgid "Gateway: 192.0.2.1 with MAC address *TG1*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:227 ../scenario-provider-ovs.rst:247 msgid "Provider network 2" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:229 ../scenario-provider-ovs.rst:249 msgid "Network: 198.51.100.0/24" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:230 ../scenario-provider-ovs.rst:250 msgid "Gateway: 198.51.100.1 with MAC address *TG2*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:234 ../scenario-provider-lb.rst:298 #: ../scenario-provider-ovs.rst:254 ../scenario-provider-ovs.rst:325 msgid "Instance 1: 192.0.2.11 with MAC address *I1*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:238 ../scenario-provider-ovs.rst:258 msgid "Instance 2: 198.51.100.11 with MAC address *I2*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:240 ../scenario-provider-ovs.rst:260 msgid "Instance 1 resides on compute node 1 and uses provider network 1." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:241 ../scenario-provider-ovs.rst:261 msgid "Instance 2 resides on compute node 2 and uses provider network 2." msgstr "" #: ../scenario-provider-lb.rst:246 msgid "" "The instance 1 ``tap`` interface forwards the packet to the provider bridge " "``qbr``. The packet contains destination MAC address *TG1* because the " "destination resides on another network." msgstr "" #: ../scenario-provider-lb.rst:249 msgid "" "Security group rules on the provider bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-provider-lb.rst:255 ../scenario-provider-lb.rst:320 msgid "" "The logical VLAN interface ``device.sid`` forwards the packet to the " "physical network infrastructure via the physical provider interface." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:260 ../scenario-provider-ovs.rst:222 #: ../scenario-provider-ovs.rst:284 msgid "" "A switch (3) handles any VLAN tag operations between provider network 1 and " "the router (4)." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:262 ../scenario-provider-ovs.rst:286 msgid "" "A router (4) routes the packet from provider network 1 to provider network 2." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:264 ../scenario-provider-ovs.rst:288 msgid "" "A switch (3) handles any VLAN tag operations between the router (4) and " "provider network 2." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:266 ../scenario-provider-ovs.rst:290 msgid "A switch (3) forwards the packet to compute node 2." msgstr "" #: ../scenario-provider-lb.rst:270 ../scenario-provider-lb.rst:329 msgid "" "The physical provider interface forwards the packet to the logical VLAN " "interface ``device.sid`` where *device* references the underlying physical " "provider interface and *sid* contains the provider network segmentation ID." msgstr "" #: ../scenario-provider-lb.rst:274 ../scenario-provider-lb.rst:333 msgid "" "The logical VLAN interface ``device.sid`` forwards the packet to the " "provider bridge ``qbr``." msgstr "" #: ../scenario-provider-lb.rst:276 msgid "" "Security group rules (5) on the provider bridge ``qbr`` handle firewalling " "and state tracking for the packet." msgstr "" #: ../scenario-provider-lb.rst:278 msgid "" "The provider bridge ``qbr`` forwards the packet to the ``tap`` interface (6) " "on instance 2." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:287 ../scenario-provider-ovs.rst:314 msgid "Case 3: East-west for instances on the same network" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:289 ../scenario-provider-ovs.rst:316 msgid "" "The physical network infrastructure handles switching within the provider " "network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:292 ../scenario-provider-ovs.rst:319 msgid "Provider network" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:302 ../scenario-provider-ovs.rst:329 msgid "Instance 2: 192.0.2.12 with MAC address *I2*" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:306 ../scenario-provider-ovs.rst:333 msgid "Both instances use the same provider network." msgstr "" #: ../scenario-provider-lb.rst:311 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the provider " "bridge ``qbr``. The packet contains destination MAC address *I2* because the " "destination resides on the same network." msgstr "" #: ../scenario-provider-lb.rst:314 msgid "" "Security group rules (2) on the provider bridge ``qbr`` handle firewalling " "and state tracking for the packet." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:325 ../scenario-provider-ovs.rst:356 msgid "A switch (3) forwards the packet from compute node 1 to compute node 2." msgstr "" #: ../scenario-provider-lb.rst:335 msgid "" "Security group rules (4) on the provider bridge ``qbr`` handle firewalling " "and state tracking for the packet." msgstr "" #: ../scenario-provider-lb.rst:337 msgid "" "The provider bridge ``qbr`` forwards the packet to the instance 2 ``tap`` " "interface (5)." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:354 ../scenario-provider-ovs.rst:387 msgid "" "To further simplify this scenario, we recommend using a configuration drive " "rather than the conventional metadata agent to provide instance metadata." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:370 ../scenario-provider-ovs.rst:403 msgid "" "The ``service_plugins`` option contains no value because the Networking " "service does not provide layer-3 services such as routing. However, this " "breaks portions of the dashboard that manage the Networking service. See the " "`Installation Guide `__ for more information." msgstr "" #: ../scenario-provider-lb.rst:377 msgid "" "Configure the ML2 plug-in and Linux bridge agent. Edit the :file:`/etc/" "neutron/plugins/ml2/ml2_conf.ini` file:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:397 ../scenario-provider-lb.rst:471 #: ../scenario-provider-ovs.rst:481 ../scenario-provider-ovs.rst:532 msgid "" "Replace ``PROVIDER_INTERFACE`` with the name of the underlying interface " "that handles provider networks. For example, ``eth1``." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:401 ../scenario-provider-ovs.rst:431 msgid "" "The ``tenant_network_types`` option contains no value because the " "architecture does not support project (private) networks." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:405 ../scenario-provider-ovs.rst:435 msgid "" "The ``provider`` value in the ``network_vlan_ranges`` option lacks VLAN ID " "ranges to support use of arbitrary VLAN IDs." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:426 ../scenario-provider-ovs.rst:453 msgid "" "Configure the DHCP agent. Edit the ``/etc/neutron/dhcp_agent.ini`` file:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:499 ../scenario-provider-ovs.rst:560 msgid "" "This example creates a VLAN provider network. Change the VLAN ID and IP " "address range to values suitable for your environment." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:503 ../scenario-provider-ovs.rst:564 msgid "Create a provider network:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:528 ../scenario-provider-ovs.rst:589 msgid "The ``shared`` option allows any project to use this network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:530 ../scenario-provider-ovs.rst:591 msgid "Create a subnet on the provider network:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:558 ../scenario-provider-ovs.rst:619 msgid "On the controller node, verify creation of the ``qdhcp`` namespace:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:589 ../scenario-provider-ovs.rst:650 msgid "Launch an instance with an interface on the provider network." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:592 ../scenario-provider-ovs.rst:653 msgid "" "This example uses a CirrOS image that was manually uploaded into the Image " "Service" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:631 ../scenario-provider-ovs.rst:692 msgid "" "Determine the IP address of the instance. The following step uses " "203.0.113.3." msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:644 ../scenario-provider-ovs.rst:705 msgid "" "On the controller node or any host with access to the provider network, ping " "the IP address of the instance:" msgstr "" # #-#-#-#-# scenario-provider-lb.pot (Networking Guide 0.9) #-#-#-#-# # #-#-#-#-# scenario-provider-ovs.pot (Networking Guide 0.9) #-#-#-#-# #: ../scenario-provider-lb.rst:660 ../scenario-provider-ovs.rst:721 msgid "Obtain access to the instance." msgstr "" #: ../scenario-provider-ovs.rst:5 msgid "Scenario: Provider networks with Open vSwitch" msgstr "" #: ../scenario-provider-ovs.rst:7 msgid "" "This scenario describes a provider networks implementation of the OpenStack " "Networking service using the ML2 plug-in with Open vSwitch (OVS)." msgstr "" #: ../scenario-provider-ovs.rst:17 msgid "" "In many cases, operators who are already familiar with network architectures " "that rely on the physical network infrastructure can easily deploy OpenStack " "Networking on it. Over time, operators can test and implement cloud " "networking features in their environment." msgstr "" #: ../scenario-provider-ovs.rst:22 msgid "" "Before OpenStack Networking introduced Distributed Virtual Routers (DVR), " "all network traffic traversed one or more dedicated network nodes, which " "limited performance and reliability. Physical network infrastructures " "typically offer better performance and reliability than general-purpose " "hosts that handle various network operations in software." msgstr "" #: ../scenario-provider-ovs.rst:45 msgid "" "These prerequisites define the minimum physical infrastructure and OpenStack " "service dependencies that you need to deploy this scenario. For example, the " "Networking service immediately depends on the Identity service and the " "Compute service immediately depends on the Networking service. These " "dependencies lack services such as the Image service because the Networking " "service does not immediately depend on it. However, the Compute service " "depends on the Image service to launch an instance. The example " "configuration in this scenario assumes basic configuration knowledge of " "Networking service components." msgstr "" #: ../scenario-provider-ovs.rst:60 msgid "" "One controller node with two network interfaces: management and provider. " "The provider interface connects to a generic network that physical network " "infrastructure switches/routes to external networks (typically the " "Internet). The Open vSwitch bridge ``br-provider`` must contain a port on " "the provider network interface." msgstr "" #: ../scenario-provider-ovs.rst:65 msgid "" "At least two compute nodes with two network interfaces: management and " "provider. The provider interface connects to a generic network that the " "physical network infrastructure switches/routes to external networks " "(typically the Internet). The Open vSwitch bridge ``br-provider`` must " "contain a port on the provider network interface." msgstr "" #: ../scenario-provider-ovs.rst:102 msgid "" "Neutron server service, Open vSwitch service, ML2 plug-in, Open vSwitch " "agent, DHCP agent, and any dependencies." msgstr "" #: ../scenario-provider-ovs.rst:125 msgid "" "Open vSwitch agent managing virtual switches, connectivity among them, and " "interaction via virtual ports with other network components such as " "namespaces and underlying interfaces." msgstr "" #: ../scenario-provider-ovs.rst:143 msgid "" "Open vSwitch agent managing virtual switches, connectivity among them, and " "interaction via virtual ports with other network components such as Linux " "bridges and underlying interfaces." msgstr "" #: ../scenario-provider-ovs.rst:171 msgid "" "Open vSwitch uses VLANs internally to segregate networks that traverse " "bridges. The VLAN ID usually differs from the segmentation ID of the virtual " "network." msgstr "" #: ../scenario-provider-ovs.rst:207 ../scenario-provider-ovs.rst:269 #: ../scenario-provider-ovs.rst:341 msgid "" "Security group rules (2) on the Linux bridge ``qbr`` handle firewalling and " "state tracking for the packet." msgstr "" #: ../scenario-provider-ovs.rst:211 ../scenario-provider-ovs.rst:345 msgid "" "The Open vSwitch integration bridge ``br-int`` adds the internal tag for the " "provider network." msgstr "" #: ../scenario-provider-ovs.rst:213 ../scenario-provider-ovs.rst:275 #: ../scenario-provider-ovs.rst:347 msgid "" "The Open vSwitch integration bridge ``br-int`` forwards the packet to the " "Open vSwitch provider bridge ``br-provider``." msgstr "" #: ../scenario-provider-ovs.rst:215 ../scenario-provider-ovs.rst:349 msgid "" "The Open vSwitch provider bridge ``br-provider`` replaces the internal tag " "with the actual VLAN tag (segmentation ID) of the provider network." msgstr "" #: ../scenario-provider-ovs.rst:217 msgid "" "The Open vSwitch provider bridge ``br-provider`` forwards the packet to the " "physical network via the provider network interface." msgstr "" #: ../scenario-provider-ovs.rst:224 msgid "" "A router (4) routes the packet from provider network 1 to the external " "network." msgstr "" #: ../scenario-provider-ovs.rst:277 msgid "" "The Open vSwitch provider bridge ``br-provider`` replaces the internal tag " "with the actual VLAN tag (segmentation ID) of provider network 1." msgstr "" #: ../scenario-provider-ovs.rst:279 ../scenario-provider-ovs.rst:351 msgid "" "The Open vSwitch VLAN bridge ``br-provider`` forwards the packet to the " "physical network infrastructure via the provider network interface." msgstr "" #: ../scenario-provider-ovs.rst:294 ../scenario-provider-ovs.rst:360 msgid "" "The provider network interface forwards the packet to the Open vSwitch " "provider bridge ``br-provider``." msgstr "" #: ../scenario-provider-ovs.rst:296 ../scenario-provider-ovs.rst:362 msgid "" "The Open vSwitch provider bridge ``br-provider`` forwards the packet to the " "Open vSwitch integration bridge ``br-int``." msgstr "" #: ../scenario-provider-ovs.rst:298 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the actual VLAN tag " "(segmentation ID) of provider network 2 with the internal tag." msgstr "" #: ../scenario-provider-ovs.rst:338 msgid "" "The instance 1 ``tap`` interface (1) forwards the packet to the Linux bridge " "``qbr``. The packet contains destination MAC address *I2* because the " "destination resides on the same network." msgstr "" #: ../scenario-provider-ovs.rst:364 msgid "" "The Open vSwitch integration bridge ``br-int`` replaces the actual VLAN tag " "(segmentation ID) of provider network 1 with the internal tag." msgstr "" #: ../scenario-provider-ovs.rst:370 msgid "" "The Linux bridge ``qbr`` forwards the packet to the ``tap`` interface (5) on " "instance 2." msgstr "" #: ../scenario-provider-ovs.rst:410 msgid "" "Configure the ML2 plug-in. Edit the ``/etc/neutron/plugins/ml2/ml2_conf." "ini`` file:" msgstr "" #: ../scenario-provider-ovs.rst:464 ../scenario-provider-ovs.rst:515 msgid "Start the following service:" msgstr "" #: ../scenario-provider-ovs.rst:468 ../scenario-provider-ovs.rst:519 msgid "Create the Open vSwitch provider bridge ``br-provider``:" msgstr "" #: ../scenario-provider-ovs.rst:474 ../scenario-provider-ovs.rst:525 msgid "" "Add the provider network interface as a port on the Open vSwitch provider " "bridge ``br-provider``:" msgstr ""