msgid "There will be three hosts in the setup. <table rules=\"all\"><caption>Hosts for demo</caption><thead><tr><th>Host</th><th>Description</th></tr></thead><tbody><tr><td>OpenStack Controller host - controlnode</td><placeholder-1/></tr><tr><td>HostA</td><td>Runs Nova compute, the Neutron L2 agent and DHCP agent</td></tr><tr><td>HostB</td><td>Same as HostA</td></tr></tbody></table>"
msgid "This example uses VLAN segmentation on the switches to isolate tenant networks. This configuration labels the physical network associated with the public network as <literal>physnet1</literal>, and the physical network associated with the data network as <literal>physnet2</literal>, which leads to the following configuration options in <filename>ovs_neutron_plugin.ini</filename>: <placeholder-1/>"
msgid "Scenario 1: one tenant, two networks, one router"
msgstr ""
@@ -5823,19 +5829,19 @@ msgstr ""
msgid "The first scenario has two private networks (<literal>net01</literal>, and <literal>net02</literal>), each with one subnet (<literal>net01_subnet01</literal>: 192.168.101.0/24, <literal>net02_subnet01</literal>, 192.168.102.0/24). Both private networks are attached to a router that connects them to the public network (10.64.201.0/24)."
msgid "Under the <literal>service</literal> tenant, create the shared router, define the public network, and set it as the default gateway of the router<placeholder-1/>"
msgid "Under the <literal>demo</literal> user tenant, create the private network <literal>net01</literal> and corresponding subnet, and connect it to the <literal>router01</literal> router. Configure it to use VLAN ID 101 on the physical switch.<placeholder-1/>"
msgid "There are four distinct type of virtual networking devices: TAP devices, veth pairs, Linux bridges, and Open vSwitch bridges. For an ethernet frame to travel from <literal>eth0</literal> of virtual machine <literal>vm01</literal> to the physical network, it must pass through nine devices inside of the host: TAP <literal>vnet0</literal>, Linux bridge <literal>qbr<replaceable>nnn</replaceable></literal>, veth pair <literal>(qvb<replaceable>nnn</replaceable>, qvo<replaceable>nnn</replaceable>)</literal>, Open vSwitch bridge <literal>br-int</literal>, veth pair <literal>(int-br-eth1, phy-br-eth1)</literal>, and, finally, the physical network interface card <literal>eth1</literal>."
msgid "A <emphasis role=\"italic\">TAP device</emphasis>, such as <literal>vnet0</literal> is how hypervisors such as KVM and Xen implement a virtual network interface card (typically called a VIF or vNIC). An ethernet frame sent to a TAP device is received by the guest operating system."
msgstr ""
@@ -5859,7 +5865,7 @@ msgstr ""
msgid "A <emphasis role=\"italic\">veth pair</emphasis> is a pair of directly connected virtual network interfaces. An ethernet frame sent to one end of a veth pair is received by the other end of a veth pair. Networking uses veth pairs as virtual patch cables to make connections between virtual bridges."
msgid "A <emphasis role=\"italic\">Linux bridge</emphasis> behaves like a hub: you can connect multiple (physical or virtual) network interfaces devices to a Linux bridge. Any ethernet frames that come in from one interface attached to the bridge is transmitted to all of the other devices."
msgstr ""
@@ -5903,7 +5909,7 @@ msgstr ""
msgid "Networking uses an extra Linux bridge and a veth pair as a workaround for this issue. Instead of connecting <literal>vnet0</literal> to an Open vSwitch bridge, it is connected to a Linux bridge, <literal>qbr<replaceable>XXX</replaceable></literal>. This bridge is connected to the integration bridge, <literal>br-int</literal>, through the <literal>(qvb<replaceable>XXX</replaceable>, qvo<replaceable>XXX</replaceable>)</literal> veth pair."
msgid "Under the <literal>service</literal> tenant, define the public network:<placeholder-1/>"
msgstr ""
@@ -6003,11 +6009,11 @@ msgstr ""
msgid "Under the <literal>tenantA</literal> user tenant, create the tenant router and set its gateway for the public network.<placeholder-1/> Then, define private network <literal>net01</literal> using VLAN ID 101 on the physical switch, along with its subnet, and connect it to the router. <placeholder-2/>"
msgid "The compute host configuration resembles the configuration in scenario 1. However, in scenario 1, a guest connects to two subnets while in this scenario, the subnets belong to different tenants."
msgid "The following figure shows the network devices on the network host for the second scenario."
msgstr ""
@@ -6035,123 +6041,167 @@ msgstr ""
msgid "In this scenario, there are four network namespaces (<literal>qhdcp-<replaceable>aaa</replaceable></literal>, <literal>qrouter-<replaceable>bbbb</replaceable></literal>, <literal>qrouter-<replaceable>cccc</replaceable></literal>, and <literal>qhdcp-<replaceable>dddd</replaceable></literal>), instead of three. Since there is no connectivity between the two networks, and so each router is implemented by a separate namespace."
msgid "This section describes how the Linux Bridge plug-in implements the Networking abstractions. For information about DHCP and L3 agents, see <xref linkend=\"under_the_hood_openvswitch_scenario1\"/>."
msgid "This example uses VLAN isolation on the switches to isolate tenant networks. This configuration labels the physical network associated with the public network as <literal>physnet1</literal>, and the physical network associated with the data network as <literal>physnet2</literal>, which leads to the following configuration options in <filename>linuxbridge_conf.ini</filename>: <placeholder-1/>"
msgid "Tunneling encapsulates network traffic between physical Networking hosts and allows VLANs to span multiple physical hosts. Instances communicate as if they share the same layer 2 network. Open vSwitch supports tunneling with the VXLAN and GRE encapsulation protocols."
msgid "This diagram shows two instances running on separate hosts connected by a VXLAN tunnel. The required physical and virtual components are also illustrated. The following procedure creates a VXLAN or GRE tunnel between two Open vSwitches running on separate Networking hosts:"
msgid "The first scenario has two private networks (<literal>net01</literal>, and <literal>net02</literal>), each with one subnet (<literal>net01_subnet01</literal>: 192.168.101.0/24, <literal>net02_subnet01</literal>, 192.168.102.0/24). Both private networks are attached to a router that contains them to the public network (10.64.201.0/24)."
msgid "Create a virtual bridge named OVS-BR0 on each participating host:"
msgid "Create a tunnel to link the OVS-BR0 virtual bridges. Run the ovs-vsctl command on HOST1 to create the tunnel and link it to the bridge on HOST2:"
msgid "There are three distinct type of virtual networking devices: TAP devices, VLAN devices, and Linux bridges. For an ethernet frame to travel from <literal>eth0</literal> of virtual machine <literal>vm01</literal>, to the physical network, it must pass through four devices inside of the host: TAP <literal>vnet0</literal>, Linux bridge <literal>brq<replaceable>XXX</replaceable></literal>, VLAN <literal>eth1.101)</literal>, and, finally, the physical network interface card <literal>eth1</literal>."
msgid "This section describes how the Linux Bridge plug-in implements the Networking abstractions. For information about DHCP and L3 agents, see <xref linkend=\"under_the_hood_openvswitch_scenario1\"/>."
msgid "A <emphasis role=\"italic\">VLAN device</emphasis> is associated with a VLAN tag attaches to an existing interface device and adds or removes VLAN tags. In the preceding example, VLAN device <literal>eth1.101</literal> is associated with VLAN ID 101 and is attached to interface <literal>eth1</literal>. Packets received from the outside by <literal>eth1</literal> with VLAN tag 101 will be passed to device <literal>eth1.101</literal>, which will then strip the tag. In the other direction, any ethernet frame sent directly to eth1.101 will have VLAN tag 101 added and will be forward to <literal>eth1</literal> for sending out to the network."
msgid "This example uses VLAN isolation on the switches to isolate tenant networks. This configuration labels the physical network associated with the public network as <literal>physnet1</literal>, and the physical network associated with the data network as <literal>physnet2</literal>, which leads to the following configuration options in <filename>linuxbridge_conf.ini</filename>: <placeholder-1/>"
msgid "The second scenario has two tenants (A, B). Each tenant has a network with one subnet, and each one has a router that connects them to the public Internet."
msgid "The first scenario has two private networks (<literal>net01</literal>, and <literal>net02</literal>), each with one subnet (<literal>net01_subnet01</literal>: 192.168.101.0/24, <literal>net02_subnet01</literal>, 192.168.102.0/24). Both private networks are attached to a router that contains them to the public network (10.64.201.0/24)."
msgid "There are three distinct type of virtual networking devices: TAP devices, VLAN devices, and Linux bridges. For an ethernet frame to travel from <literal>eth0</literal> of virtual machine <literal>vm01</literal>, to the physical network, it must pass through four devices inside of the host: TAP <literal>vnet0</literal>, Linux bridge <literal>brq<replaceable>XXX</replaceable></literal>, VLAN <literal>eth1.101)</literal>, and, finally, the physical network interface card <literal>eth1</literal>."
msgid "A <emphasis role=\"italic\">VLAN device</emphasis> is associated with a VLAN tag attaches to an existing interface device and adds or removes VLAN tags. In the preceding example, VLAN device <literal>eth1.101</literal> is associated with VLAN ID 101 and is attached to interface <literal>eth1</literal>. Packets received from the outside by <literal>eth1</literal> with VLAN tag 101 will be passed to device <literal>eth1.101</literal>, which will then strip the tag. In the other direction, any ethernet frame sent directly to eth1.101 will have VLAN tag 101 added and will be forward to <literal>eth1</literal> for sending out to the network."
msgid "The second scenario has two tenants (A, B). Each tenant has a network with one subnet, and each one has a router that connects them to the public Internet."
msgid "Under the <literal>tenantA</literal> user tenant, create the tenant router and set its gateway for the public network.<placeholder-1/> Then, define private network <literal>net01</literal> using VLAN ID 102 on the physical switch, along with its subnet, and connect it to the router. <placeholder-2/>"
msgid "The configuration on the compute host is very similar to the configuration in scenario 1. The only real difference is that scenario 1 had a guest connected to two subnets, and in this scenario the subnets belong to different tenants."
msgid "The main difference between the configuration in this scenario and the previous one is the organization of the network namespaces, in order to provide isolation across the two subnets, as shown in the following figure."
msgid "In this scenario, there are four network namespaces (<literal>qhdcp-<replaceable>aaa</replaceable></literal>, <literal>qrouter-<replaceable>bbbb</replaceable></literal>, <literal>qrouter-<replaceable>cccc</replaceable></literal>, and <literal>qhdcp-<replaceable>dddd</replaceable></literal>), instead of three. Each router is implemented by a separate namespace, since there is no connectivity between the two networks."
msgid "The Modular Layer 2 plug-in allows OpenStack Networking to simultaneously utilize the variety of layer 2 networking technologies found in complex real-world data centers. It currently includes drivers for the local, flat, VLAN, GRE and VXLAN network types and works with the existing <emphasis>Open vSwitch</emphasis>, <emphasis>Linux Bridge </emphasis>, and <emphasis>HyperV</emphasis> L2 agents. The <emphasis>ML2</emphasis> plug-in can be extended through mechanism drivers, allowing multiple mechanisms to be used simultaneously. This section describes different <emphasis>ML2</emphasis> plug-in and agent configurations with different type drivers and mechanism drivers."
msgid "Previously, Networking deployments were only able to use the plug-in that had been selected at implementation time. For example, a deployment running the Open vSwitch plug-in was only able to use Open vSwitch exclusively; it wasn't possible to simultaneously run another plug-in such as Linux Bridge. This was found to be a limitation in environments with heterogeneous requirements."
msgid "The L2 Population driver enables broadcast, multicast, and unicast traffic to scale out on large overlay networks. This traffic is sent to the relevant agent via encapsulation as a targeted unicast."
msgid "Current <emphasis>Open vSwitch</emphasis> and <emphasis>Linux Bridge</emphasis> tunneling implementations broadcast to every agent, even if they don’t host the corresponding network as illustrated below."
msgid "As broadcast emulation on overlay is costly, it may be better to avoid its use for MAC learning and ARP resolution. This supposes the use of proxy ARP on the agent to answer VM requests, and to populate forwarding table. Currently only the <emphasis>Linux Bridge</emphasis> Agent implements an ARP proxy. The prepopulation limits L2 broadcasts in overlay, however it may anyway be necessary to provide broadcast emulation. This is achieved by broadcasting packets via unicast only to the relevant agents as illustrated below.<placeholder-1/>The partial-mesh is available with the <emphasis>Open vSwitch</emphasis> and <emphasis>Linux Bridge</emphasis> agents. The following scenarios will use the L2 population mechanism driver with an <emphasis>Open vSwitch</emphasis> agent and a <emphasis>Linux Bridge</emphasis> agent. Enable the l2 population driver by adding it to the list of mechanism drivers. In addition, a tunneling driver must be selected. Supported options are GRE, VXLAN, or a combination of both. Configuration settings are enabled in <filename>ml2_conf.ini</filename>:<placeholder-2/>"
msgid "Enable the l2 population extension in the <emphasis>Open vSwitch</emphasis> agent, and configure the <option>local_ip</option> and <option>tunnel_types</option> parameters in the <filename>ml2_conf.ini</filename> file: <placeholder-1/>"
msgid "Enable the l2 population extension on the <emphasis>Linux Bridge</emphasis> agent. Enable VXLAN and configure the local_ip parameter in <filename>ml2_conf.ini</filename>. <placeholder-1/>"
msgid "Since the ML2 plug-in can concurrently support different L2 agents (or other mechanisms) with different configuration files, the actual <option>firewall_driver </option> value in the <filename>ml2_conf.ini</filename> file does not matter in the server, but <option>firewall_driver</option> must be set to a non-default value in the ml2 configuration to enable the securitygroup extension. To enable securitygroup API, edit the <filename>ml2_conf.ini</filename> file:<placeholder-1/> Each L2 agent configuration file (such as <filename>ovs_neutron_plugin.ini</filename> or <filename>linuxbridge_conf.ini</filename>) should contain the appropriate <option>firewall_driver</option> value for that agent. To disable securitygroup API, edit the<filename>ml2_conf.ini</filename> file:<placeholder-2/> Also, each L2 agent configuration file (such as <filename>ovs_neutron_plugin.ini</filename> or <filename>linuxbridge_conf.ini</filename>) should contain this value in <option>firewall_driver</option> parameter for that agent."
msgid "Run the following command to purge expired tokens every hour and log the output to <filename>/var/log/keystone/keystone-tokenflush.log</filename>:"
msgid "For reliability, you add proxy servers. You can set up an additional proxy node the same way that you set up the first proxy node but with additional configuration steps."
msgid "After you have more than two proxies, you must load balance them; your storage endpoint (what clients use to connect to your storage) also changes. You can select from different strategies for load balancing. For example, you could use round-robin DNS, or a software or hardware load balancer (like pound) in front of the two proxies, and point your storage URL to the load balancer."
msgid "Update the list of memcache servers in the <filename>/etc/swift/proxy-server.conf</filename> file for added proxy servers. If you run multiple memcache servers, use this pattern for the multiple IP:port listings in each proxy server configuration file:"
msgid "Modify memcached to listen on the default interface on a local, non-public network. Edit the <filename>/etc/sysconfig/memcached</filename> file:"
msgstr ""
@@ -5032,6 +5000,34 @@ msgstr ""
msgid "Start the Proxy service and configure it to start when the system boots:"
msgid "To provide additional reliability, and bandwidth to your cluster, you add proxy servers. You can set up an additional proxy node the same way that you set up the first proxy node but with additional configuration steps."
msgid "After you have more than two proxies, you must load balance them; your storage endpoint (what clients use to connect to your storage) also changes. You can select from different strategies for load balancing. For example, you could use round-robin DNS, or a software or hardware load balancer (like pound) in front of the two proxies, and point your storage URL to the load balancer."
msgid "Update the list of memcache servers in the <filename>/etc/swift/proxy-server.conf</filename> file for added proxy servers. If you run multiple memcache servers, use this pattern for the multiple IP:port listings in each proxy server configuration file:"
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
OpenStack Jenkins