b390e59445
Applied systemitem and programlisting tags where indicated by reviewers Deleted extra spaces after =s and also other white spaces Fixed a couple of typos - major copyedit to be done under another bug Closes-bug: 1223542 Change-Id: Ia4ecbdb304e18a42769b50d52d33e3757710fe5b Author: Nermina Miller
1388 lines
72 KiB
XML
1388 lines
72 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||
xml:id="ch_adv_features">
|
||
<title>Advanced Features through API Extensions</title>
|
||
<para>This section discusses two API extensions that are
|
||
implemented by several plugins. Because these extensions
|
||
provide capabilities similar to what was available in
|
||
nova-network, they are likely to be of interest to a large
|
||
portion of the OpenStack community. </para>
|
||
<section xml:id="provider_networks">
|
||
<title>Provider Networks</title>
|
||
<para>Provider networks enable cloud administrators to create
|
||
OpenStack Networking networks that map directly to
|
||
physical networks in the data center. This is commonly
|
||
used to give tenants direct access to a "public" network
|
||
that can be used to reach the Internet. It may also be
|
||
used to integrate with VLANs in the network that already
|
||
have a defined meaning (e.g., allow a VM from the
|
||
"marketing" department to be placed on the same VLAN as
|
||
bare-metal marketing hosts in the same data
|
||
center).</para>
|
||
<para>The provider extension allows administrators to
|
||
explicitly manage the relationship between OpenStack
|
||
Networking virtual networks and underlying physical
|
||
mechanisms such as VLANs and tunnels. When this extension
|
||
is supported, OpenStack Networking client users with
|
||
administrative privileges see additional provider
|
||
attributes on all virtual networks, and are able to
|
||
specify these attributes in order to create provider
|
||
networks.</para>
|
||
<para>The provider extension is supported by the openvswitch
|
||
and linuxbridge plugins. Configuration of these plugins
|
||
requires familiarity with this extension.</para>
|
||
<section xml:id="provider_terminology">
|
||
<title>Terminology</title>
|
||
<para>A number of terms are used in the provider extension
|
||
and in the configuration of plugins supporting the
|
||
provider extension:<itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">virtual
|
||
network</emphasis> - An OpenStack
|
||
Networking L2 network (identified by a
|
||
UUID and optional name) whose ports can be
|
||
attached as vNICs to OpenStack Compute
|
||
instances and to various OpenStack
|
||
Networking agents. The openvswitch and
|
||
linuxbridge plugins each support several
|
||
different mechanisms to realize virtual
|
||
networks.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">physical
|
||
network</emphasis> - A network
|
||
connecting virtualization hosts (i.e.
|
||
OpenStack Compute nodes) with each other
|
||
and with other network resources. Each
|
||
physical network may support multiple
|
||
virtual networks. The provider extension
|
||
and the plugin configurations identify
|
||
physical networks using simple string
|
||
names.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">tenant
|
||
network</emphasis> - A "normal"
|
||
virtual network created by/for a tenant.
|
||
The tenant is not aware of how that
|
||
network is physically realized.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">provider
|
||
network</emphasis> - A virtual network
|
||
administratively created to map to a
|
||
specific network in the data center,
|
||
typically to enable direct access to
|
||
non-OpenStack resources on that network.
|
||
Tenants can be given access to provider
|
||
networks.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">VLAN
|
||
network</emphasis> - A virtual network
|
||
realized as packets on a specific physical
|
||
network containing IEEE 802.1Q headers
|
||
with a specific VID field value. VLAN
|
||
networks sharing the same physical network
|
||
are isolated from each other at L2, and
|
||
can even have overlapping IP address
|
||
spaces. Each distinct physical network
|
||
supporting VLAN networks is treated as a
|
||
separate VLAN trunk, with a distinct space
|
||
of VID values. Valid VID values are 1
|
||
through 4094.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">flat
|
||
network</emphasis> - A virtual network
|
||
realized as packets on a specific physical
|
||
network containing no IEEE 802.1Q header.
|
||
Each physical network can realize at most
|
||
one flat network.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">local
|
||
network</emphasis> - A virtual network
|
||
that allows communication within each
|
||
host, but not across a network. Local
|
||
networks are intended mainly for
|
||
single-node test scenarios, but may have
|
||
other uses.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">GRE
|
||
network</emphasis> - A virtual network
|
||
realized as network packets encapsulated
|
||
using GRE. GRE networks are also referred
|
||
to as "tunnels". GRE tunnel packets are
|
||
routed by the host's IP routing table, so
|
||
GRE networks are not associated by
|
||
OpenStack Networking with specific
|
||
physical networks.</para>
|
||
</listitem>
|
||
</itemizedlist></para>
|
||
<para>Both the openvswitch and linuxbridge plugins support
|
||
VLAN networks, flat networks, and local networks. Only
|
||
the openvswitch plugin currently supports GRE
|
||
networks, provided that the host's Linux kernel
|
||
supports the required Open vSwitch features.</para>
|
||
</section>
|
||
<section xml:id="provider_attributes">
|
||
<title>Provider Attributes</title>
|
||
<para>The provider extension extends the OpenStack
|
||
Networking network resource with the following three
|
||
additional attributes:</para>
|
||
<table rules="all">
|
||
<caption>Provider Network Attributes</caption>
|
||
<col width="25%"/>
|
||
<col width="10%"/>
|
||
<col width="25%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>provider:network_type</td>
|
||
<td>String</td>
|
||
<td>N/A</td>
|
||
<td>The physical mechanism by which the
|
||
virtual network is realized. Possible
|
||
values are "flat", "vlan", "local", and
|
||
"gre", corresponding to flat networks,
|
||
VLAN networks, local networks, and GRE
|
||
networks as defined above. All types of
|
||
provider networks can be created by
|
||
administrators, while tenant networks can
|
||
be realized as "vlan", "gre", or "local"
|
||
network types depending on plugin
|
||
configuration.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>provider:physical_network</td>
|
||
<td>String</td>
|
||
<td>If a physical network named "default" has
|
||
been configured, and if
|
||
provider:network_type is "flat" or "vlan",
|
||
then "default" is used.</td>
|
||
<td>The name of the physical network over
|
||
which the virtual network is realized for
|
||
flat and VLAN networks. Not applicable to
|
||
the "local" or "gre" network types.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>provider:segmentation_id</td>
|
||
<td>Integer</td>
|
||
<td>N/A</td>
|
||
<td>For VLAN networks, the VLAN VID on the
|
||
physical network that realizes the virtual
|
||
network. Valid VLAN VIDs are 1 through
|
||
4094. For GRE networks, the tunnel ID.
|
||
Valid tunnel IDs are any 32 bit unsigned
|
||
integer. Not applicable to the "flat" or
|
||
"local" network types.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<para>The provider attributes are returned by OpenStack
|
||
Networking API operations when the client is
|
||
authorized for the
|
||
<code>extension:provider_network:view</code>
|
||
action via the OpenStack Networking policy
|
||
configuration. The provider attributes are only
|
||
accepted for network API operations if the client is
|
||
authorized for the
|
||
<code>extension:provider_network:set</code>
|
||
action. The default OpenStack Networking API policy
|
||
configuration authorizes both actions for users with
|
||
the admin role. See ch_auth for
|
||
details on policy configuration.</para>
|
||
</section>
|
||
<section xml:id="provider_api_workflow">
|
||
<title>Provider API Workflow</title>
|
||
<para>Show all attributes of a network, including provider
|
||
attributes when invoked with the admin role:</para>
|
||
<para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-show <name or net-id></userinput></screen>
|
||
</para>
|
||
<para>Create a local provider network (admin-only):</para>
|
||
<para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-create <name> --tenant_id <tenant-id> --provider:network_type local</userinput></screen>
|
||
</para>
|
||
<para>Create a flat provider network (admin-only):</para>
|
||
<para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-create <name> --tenant_id <tenant-id> --provider:network_type flat --provider:physical_network <phys-net-name></userinput></screen>
|
||
</para>
|
||
<para>Create a VLAN provider network (admin-only):</para>
|
||
<para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-create <name> --tenant_id <tenant-id> --provider:network_type vlan --provider:physical_network <phys-net-name> --provider:segmentation_id <VID></userinput></screen>
|
||
</para>
|
||
<para>Create a GRE provider network (admin-only):</para>
|
||
<para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-create <name> --tenant_id <tenant-id> --provider:network_type gre --provider:segmentation_id <tunnel-id></userinput></screen>
|
||
</para>
|
||
<para>When creating flat networks or VLAN networks, <phys-net-name> must be known to the plugin. See ovs_neutron_plugin and linuxbridge_conf for details on configuring network_vlan_ranges to identify all physical networks. When creating VLAN networks, <VID> can fall either within or outside any configured ranges of VLAN IDs from which tenant networks are allocated. Similarly, when creating GRE networks, <tunnel-id> can fall either within or outside any tunnel ID ranges from which tenant networks are allocated.</para>
|
||
<para>Once provider networks have been created, subnets can be allocated and they can be used similarly to other virtual networks, subject to authorization
|
||
policy based on the specified <tenant_id>.</para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="l3_router_and_nat">
|
||
<title>L3 Routing and NAT</title>
|
||
<para>Just like the core OpenStack Networking API provides
|
||
abstract L2 network segments that are decoupled from the
|
||
technology used to implement the L2 network, OpenStack
|
||
Networking includes an API extension that provides
|
||
abstract L3 routers that API users can dynamically
|
||
provision and configure. These OpenStack Networking
|
||
routers can connect multiple L2 OpenStack Networking
|
||
networks, and can also provide a "gateway" that connects
|
||
one or more private L2 networks to a shared "external"
|
||
network (e.g., a public network for access to the
|
||
Internet). See use_cases_single_router
|
||
and use_cases_tenant_router for details
|
||
on common models of deploying OpenStack Networking L3
|
||
routers.</para>
|
||
<para>The L3 router provides basic NAT capabilities on
|
||
"gateway" ports that uplink the router to external
|
||
networks. This router SNATs all traffic by default, and
|
||
supports "Floating IPs", which creates a static one-to-one
|
||
mapping from a public IP on the external network to a
|
||
private IP on one of the other subnets attached to the
|
||
router. This allows a tenant to selectively expose VMs on
|
||
private networks to other hosts on the external network
|
||
(and often to all hosts on the Internet). Floating IPs can
|
||
be allocated and then mapped from one OpenStack Networking
|
||
port to another, as needed.</para>
|
||
<section xml:id="l3_api_abstractions">
|
||
<title>L3 API Abstractions</title>
|
||
<table rules="all">
|
||
<caption>Router</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the router.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>name</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human-readable name for the router. Might
|
||
not be unique.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>admin_state_up</td>
|
||
<td>Bool</td>
|
||
<td>True</td>
|
||
<td>The administrative state of router. If
|
||
false (down), the router does not forward
|
||
packets.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>status</td>
|
||
<td>String</td>
|
||
<td>N/A</td>
|
||
<td><para>Indicates whether router is
|
||
currently operational.</para></td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the router. Only admin users can
|
||
specify a tenant_id other than its own.
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td>external_gateway_info</td>
|
||
<td>dict contain 'network_id' key-value
|
||
pair</td>
|
||
<td>Null</td>
|
||
<td>External network that this router connects
|
||
to for gateway services (e.g., NAT)</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<table rules="all">
|
||
<caption>Floating IP</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the floating IP.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>floating_ip_address</td>
|
||
<td>string (IP address)</td>
|
||
<td>allocated by OpenStack Networking</td>
|
||
<td>The external network IP address available
|
||
to be mapped to an internal IP
|
||
address.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>floating_network_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td><para>The network indicating the set of
|
||
subnets from which the floating IP
|
||
should be allocated</para></td>
|
||
</tr>
|
||
<tr>
|
||
<td>router_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Read-only value indicating the router that
|
||
connects the external network to the
|
||
associated internal port, if a port is
|
||
associated.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>port_id</td>
|
||
<td>uuid-str</td>
|
||
<td>Null</td>
|
||
<td>Indicates the internal OpenStack
|
||
Networking port associated with the
|
||
external floating IP.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>fixed_ip_address</td>
|
||
<td>string (IP address)</td>
|
||
<td>Null</td>
|
||
<td>Indicates the IP address on the internal
|
||
port that is mapped to by the floating IP
|
||
(since an OpenStack Networking port might
|
||
have more than one IP address).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the Floating IP. Only admin users
|
||
can specify a tenant_id other than its
|
||
own.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
</section>
|
||
<section xml:id="l3_workflow">
|
||
<title>Common L3 Workflow</title>
|
||
<para>Create external networks (admin-only)</para>
|
||
<screen><computeroutput>neutron net-create public --router:external=True
|
||
neutron subnet-create public 172.16.1.0/24 --disable-dhcp</computeroutput></screen>
|
||
<para>Viewing external networks:</para>
|
||
<screen><computeroutput>neutron net-list -- --router:external=True</computeroutput></screen>
|
||
<para>Creating routers</para>
|
||
<para>Internal-only router to connect multiple L2 networks
|
||
privately.</para>
|
||
<screen><computeroutput>neutron net-create net1
|
||
neutron subnet-create net1 10.0.0.0/24
|
||
neutron net-create net2
|
||
neutron subnet-create net2 10.0.1.0/24
|
||
neutron router-create router1
|
||
neutron router-interface-add router1 <subnet1-uuid>
|
||
neutron router-interface-add router1 <subnet2-uuid></computeroutput></screen>
|
||
<para>The router will get an interface with the gateway_ip
|
||
address of the subnet, and this interface will be
|
||
attached to a port on the L2 OpenStack Networking
|
||
network associated with the subnet. The router will
|
||
also get an gateway interface to the specified
|
||
external network. This will provide SNAT connectivity
|
||
to the external network as well as support for
|
||
floating IPs allocated on that external networks (see
|
||
below). Commonly an external network maps to a
|
||
network in the provider</para>
|
||
<para>A router can also be connected to an “external
|
||
network”, allowing that router to act as a NAT gateway
|
||
for external connectivity.</para>
|
||
<screen><computeroutput>neutron router-gateway-set router1 <ext-net-id> </computeroutput></screen>
|
||
<para>Viewing routers:</para>
|
||
<para>List all routers:
|
||
<screen><computeroutput>neutron router-list</computeroutput></screen></para>
|
||
<para>Show a specific router:
|
||
<screen><computeroutput>neutron router-show <router_id></computeroutput></screen></para>
|
||
<para>Show all internal interfaces for a router:
|
||
<screen><computeroutput>neutron port-list -- --device_id=<router_id></computeroutput></screen></para>
|
||
<para>Associating / Disassociating Floating IPs:</para>
|
||
<para>First, identify the port-id representing the VM NIC
|
||
that the floating IP should map to:</para>
|
||
<screen><computeroutput>neutron port-list -c id -c fixed_ips -- --device_id=<instance_id></computeroutput></screen>
|
||
<para>This port must be on an OpenStack Networking subnet
|
||
that is attached to a router uplinked to the external
|
||
network that will be used to create the floating IP.
|
||
Conceptually, this is because the router must be able
|
||
to perform the Destination NAT (DNAT) rewriting of
|
||
packets from the Floating IP address (chosen from a
|
||
subnet on the external network) to the internal Fixed
|
||
IP (chosen from a private subnet that is “behind” the
|
||
router). </para>
|
||
<para>Create floating IP unassociated, then
|
||
associate</para>
|
||
<screen><computeroutput>neutron floatingip-create <ext-net-id>
|
||
neutron floatingip-associate <floatingip-id> <internal VM port-id> </computeroutput></screen>
|
||
<para>create floating IP and associate in a single
|
||
step</para>
|
||
<screen><computeroutput>neutron floatingip-create --port_id <internal VM port-id> <ext-net-id> </computeroutput></screen>
|
||
<para>Viewing Floating IP State:</para>
|
||
<screen><computeroutput>neutron floatingip-list</computeroutput></screen>
|
||
<para>Find floating IP for a particular VM port:</para>
|
||
<screen><computeroutput>neutron floatingip-list -- --port_id=ZZZ</computeroutput></screen>
|
||
<para>Disassociate a Floating IP:</para>
|
||
<screen><computeroutput>neutron floatingip-disassociate <floatingip-id></computeroutput></screen>
|
||
<para>L3 Tear Down</para>
|
||
<para>Delete the Floating IP:</para>
|
||
<screen><computeroutput>neutron floatingip-delete <floatingip-id> </computeroutput></screen>
|
||
<para>Then clear the gateway:</para>
|
||
<screen><computeroutput>neutron router-gateway-clear router1</computeroutput></screen>
|
||
<para>Then remove the interfaces from the router:</para>
|
||
<screen><computeroutput>neutron router-interface-delete router1 <subnet-id> </computeroutput></screen>
|
||
<para>Finally, delete the router:</para>
|
||
<screen><computeroutput>neutron router-delete router1</computeroutput></screen>
|
||
</section>
|
||
</section>
|
||
<section xml:id="securitygroups">
|
||
<title>Security Groups</title>
|
||
<para>Security groups and security group rules allows
|
||
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.</para>
|
||
<para>When a port is created in OpenStack Networking it is
|
||
associated with a security group. If a security group is
|
||
not specified the port will be associated with a 'default'
|
||
security group. By default this group will drop all
|
||
ingress traffic and allow all egress. Rules can be added
|
||
to this group in order to change the behaviour.</para>
|
||
<para>If one desires to use the OpenStack Compute security group APIs and/or have OpenStack
|
||
Compute orchestrate the creation of new ports for instances on specific security groups,
|
||
additional configuration is needed. To enable this, one must configure the following
|
||
file <filename>/etc/nova/nova.conf</filename> and set the config option
|
||
security_group_api=neutron on every node running <systemitem class="service">nova-compute</systemitem> and <systemitem class="service">nova-api</systemitem>. After this
|
||
change is made restart <systemitem class="service">nova-api</systemitem> and <systemitem class="service">nova-compute</systemitem> in order to pick up this change. After
|
||
this change is made one will be able to use both the OpenStack Compute and OpenStack
|
||
Network security group API at the same time.</para>
|
||
<note>
|
||
<itemizedlist>
|
||
<listitem><para>To use the OpenStack Compute security group API with OpenStack Networking, the OpenStack Networking plugin must implement the security group API. The
|
||
following plugins currently implement this: Nicira NVP, Open vSwitch, Linux Bridge, NEC, and Ryu.</para>
|
||
</listitem>
|
||
<listitem><para>You must configure the correct firewall driver in the <literal>securitygroup</literal> section of the plugin/agent configuration file. Some plugins and agents, such as Linux Bridge Agent and Open vSwitch Agent, use the no-operation driver as the default, which results in non-working security groups.</para>
|
||
</listitem>
|
||
<listitem><para>When using the security group API through OpenStack Compute, security groups are applied to all ports on an instance. The reason for this is that OpenStack Compute security group APIs are instances based and not port based as OpenStack Networking.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</note>
|
||
<section xml:id="securitygroup_api_abstractions">
|
||
<title>Security Group API Abstractions</title>
|
||
<table rules="all">
|
||
<caption>Security Group Attributes</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the security group.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>name</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human-readable name for the security
|
||
group. Might not be unique. Cannot be
|
||
named default as that is automatically
|
||
created for a tenant.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>description</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human-readable description of a security
|
||
group.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the security group. Only admin
|
||
users can specify a tenant_id other than
|
||
their own.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<table rules="all">
|
||
<caption>Security Group Rules</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the security group rule.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>security_group_id</td>
|
||
<td>uuid-str or Integer</td>
|
||
<td>allocated by OpenStack Networking</td>
|
||
<td>The security group to associate rule
|
||
with.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>direction</td>
|
||
<td>String</td>
|
||
<td>N/A</td>
|
||
<td>The direction the traffic is allow
|
||
(ingress/egress) from a VM.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>protocol</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>IP Protocol (icmp, tcp, udp, etc).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>port_range_min</td>
|
||
<td>Integer</td>
|
||
<td>None</td>
|
||
<td>Port at start of range</td>
|
||
</tr>
|
||
<tr>
|
||
<td>port_range_max</td>
|
||
<td>Integer</td>
|
||
<td>None</td>
|
||
<td>Port at end of range</td>
|
||
</tr>
|
||
<tr>
|
||
<td>ethertype</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>ethertype in L2 packet (IPv4, IPv6,
|
||
etc)</td>
|
||
</tr>
|
||
<tr>
|
||
<td>remote_ip_prefix</td>
|
||
<td>string (IP cidr)</td>
|
||
<td>None</td>
|
||
<td>CIDR for address range</td>
|
||
</tr>
|
||
<tr>
|
||
<td>remote_group_id</td>
|
||
<td>uuid-str or Integer</td>
|
||
<td>allocated by OpenStack Networking or
|
||
OpenStack Compute</td>
|
||
<td>Source security group to apply to
|
||
rule.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the security group rule. Only
|
||
admin users can specify a tenant_id other
|
||
than its own.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
</section>
|
||
<section xml:id="securitygroup_workflow">
|
||
<title>Common Security Group Commands</title>
|
||
<para>Create a security group for our web servers:</para>
|
||
<screen><computeroutput>
|
||
neutron security-group-create webservers --description "security group for webservers"</computeroutput></screen>
|
||
<para>Viewing security groups:</para>
|
||
<screen><computeroutput>neutron security-group-list</computeroutput></screen>
|
||
<para>Creating security group rule to allow port 80
|
||
ingress:</para>
|
||
<screen><computeroutput>
|
||
neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 80 --port_range_max 80 <security_group_uuid></computeroutput></screen>
|
||
<para>List security group rules:</para>
|
||
<screen><computeroutput>neutron security-group-rule-list </computeroutput></screen>
|
||
<para>Delete a security group rule:</para>
|
||
<screen><computeroutput>neutron security-group-rule-delete <security_group_rule_uuid></computeroutput></screen>
|
||
<para>Delete security group:</para>
|
||
<screen><computeroutput>neutron security-group-delete <security_group_uuid> </computeroutput></screen>
|
||
<para>Create a port and associated two security
|
||
groups:</para>
|
||
<screen><computeroutput>neutron port-create --security-group <security_group_id1> --security-group <security_group_id2> <network_id></computeroutput></screen>
|
||
<para>Remove security groups from a port:</para>
|
||
<screen><computeroutput>neutron port-update --no-security-groups <port_id></computeroutput></screen>
|
||
</section>
|
||
</section>
|
||
<section xml:id="lbaas">
|
||
<title>Load-Balancer-as-a-Service</title>
|
||
<note>
|
||
<para>The Load-Balancer-as-a-Service API is an
|
||
experimental API meant to give early adopters and
|
||
vendors a chance to build implementations against. The
|
||
reference implementation should probably not be run in
|
||
production environments.</para>
|
||
</note>
|
||
<section xml:id="lbaas_workflow">
|
||
<title>Common Load-Balancer-as-a-Service Workflow</title>
|
||
|
||
<itemizedlist>
|
||
|
||
<listitem>
|
||
<para><emphasis role="bold">Find the correct subnet
|
||
ID.</emphasis> The load balancer virtual IP (vip) and
|
||
the instances that provide the balanced service must all
|
||
be on the same subnet. The first step then is to obtain
|
||
a list of available subnets and their IDs:</para>
|
||
<screen><computeroutput>
|
||
neutron subnet-list</computeroutput></screen>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><emphasis role="bold">Create a load balancer
|
||
pool</emphasis> using the appropriate subnet ID from the
|
||
list obtained above:</para>
|
||
<screen><computeroutput>
|
||
neutron lb-pool-create --lb-method ROUND_ROBIN --name mypool --protocol HTTP --subnet-id <subnet-uuid></computeroutput></screen>
|
||
<para>Valid options for <code>--lb-method</code> depend on
|
||
the backend provider. For the reference implementation
|
||
based on HAProxy valid options are: ROUND_ROBIN,
|
||
LEAST_CONNECTIONS, or SOURCE_IP</para>
|
||
<para>Valid options for protocol are: HTTP, HTTPS, or TCP</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><emphasis role="bold">Associate servers</emphasis> with pool:</para>
|
||
<screen><computeroutput>
|
||
neutron lb-member-create --address <webserver one IP> --protocol-port 80 mypool
|
||
neutron lb-member-create --address <webserver two IP> --protocol-port 80 mypool</computeroutput></screen>
|
||
<para>Optionally <code>--weight</code> may be specified as
|
||
an integer in the range 0..256. The weight of a member
|
||
determines the portion of requests or connections it
|
||
services compared to the other members of the pool. A
|
||
value of 0 means the member will not participate in
|
||
load-balancing but will still accept persistent
|
||
connections.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><emphasis role="bold">Create a health
|
||
monitor</emphasis> which checks to make sure our
|
||
instances are still running on the specified
|
||
protocol-port:</para>
|
||
<screen><computeroutput>
|
||
neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3</computeroutput></screen>
|
||
<para>Valid options for <code>--type</code> are: PING,
|
||
TCP, HTTP, HTTPS. It is also possible to set
|
||
<code>--url_path</code> which defaults to "/" and if
|
||
specified must begin with a leading slash</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><emphasis role="bold">Associate health monitor with pool:</emphasis></para>
|
||
<screen><computeroutput>
|
||
neutron lb-healthmonitor-associate <healthmonitor-uuid> mypool</computeroutput></screen>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><emphasis role="bold">Create a Virtual IP Address
|
||
(VIP)</emphasis> that when accessed via the load
|
||
balancer will direct the requests to one of the pool
|
||
members:</para>
|
||
<screen><computeroutput>
|
||
neutron lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-uuid> mypool</computeroutput></screen>
|
||
<para>Values for <code>--protocol</code> here are these
|
||
same as in the pool creation step above.</para>
|
||
<para>Connection rate limiting can be implemented using
|
||
the <code>--connection-limit</code> flag and specifying
|
||
maximum connections per second.</para>
|
||
<para>As written above the load balancer will not have
|
||
persistent sessions, to define persistent sessions so
|
||
that a given client will always connect to the same
|
||
backend (so long as it is still operational) use the
|
||
following form:</para>
|
||
<screen><computeroutput>
|
||
neutron lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-uuid> --session-persistence type=dict type=<type>,[cookie_name=<name>] mypool</computeroutput></screen>
|
||
<para>Valid session persistence types are: APP_COOKIE,
|
||
HTTP_COOKIE or SOURCE_IP.</para>
|
||
<para>The APP_COOKIE type reuses a cookie from your
|
||
application to manage persistence and requires the
|
||
additional option <code>cookie_name=<name></code>
|
||
to inform the load balancer of which cookie name to use,
|
||
this <code>cookie_name</code> is unused with other
|
||
persistence types.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
</section>
|
||
<section xml:id="fwaas">
|
||
<title>Firewall-as-a-Service</title>
|
||
<para>The Firewall-as-a-Service (FWaaS) API is an
|
||
experimental API meant to give early adopters and
|
||
vendors a chance to build implementations against.</para>
|
||
|
||
<para><emphasis role="bold">Reference Implementation</emphasis>
|
||
This extension is backed by a reference implementation that
|
||
works with the Neutron OVS Plugin and provides perimeter
|
||
firewall functionality. It leverages the footprint of the
|
||
Neutron OVS L3 agent and an IPTables driver to apply the
|
||
Firewall Rules contained in a particular Firewall Policy.
|
||
This reference implementation supports one Firewall Policy
|
||
and consequently one logical Firewall instance per tenant
|
||
(this is not a constraint of the resource model, but of the
|
||
current reference implementation). The Firewall is realized
|
||
on a Neutron virtual router. If a tenant has multiple
|
||
routers, the firewall will be realized on all the routers. If
|
||
a tenant does not have any router, the firewall will be in
|
||
<code>PENDING_CREATE</code> state until a router is created
|
||
and the first interface is added to the router. At that point
|
||
the firewall policy will be immediately applied to the router
|
||
and the firewall will change to <code>ACTIVE</code>
|
||
state.</para>
|
||
<note>
|
||
<para>Since this is the first iteration of this implementation,
|
||
it should probably not be run in production environments
|
||
without adequate testing.</para>
|
||
</note>
|
||
<section xml:id="fwaas_api_abstractions">
|
||
<title>Firewall-as-a-Service API Abstractions</title>
|
||
<table rules="all">
|
||
<caption>Firewall Rules</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the Firewall Rule.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the Firewall Rule. Only
|
||
admin users can specify a tenant_id other
|
||
than its own.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>name</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human readable name for the Firewall Rule
|
||
(255 characters limit).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>description</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human readable description for the Firewall Rule
|
||
(1024 characters limit).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>firewall_policy_id</td>
|
||
<td>uuid-str or None</td>
|
||
<td>allocated by OpenStack Networking</td>
|
||
<td>This is a readonly attribute that gets populated
|
||
with the uuid of the Firewall Policy when this
|
||
Firewall Rule is associated with a Firewall
|
||
Policy. A Firewall Rule can be associated with only
|
||
one Firewall Policy at a time. However, the
|
||
association can be changed to a different Firewall
|
||
Policy.
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td>shared</td>
|
||
<td>Boolean</td>
|
||
<td>False</td>
|
||
<td>When set to True makes this Firewall Rule visible
|
||
to tenants other than its owner, and it can be used
|
||
in Firewall Policies not owned by its tenant.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>protocol</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>IP Protocol (icmp, tcp, udp, None).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>ip_version</td>
|
||
<td>Integer or String</td>
|
||
<td>4</td>
|
||
<td>IP Version (4, 6).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>source_ip_address</td>
|
||
<td>String (IP address or CIDR)</td>
|
||
<td>None</td>
|
||
<td>Source IP address or CIDR.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>destination_ip_address</td>
|
||
<td>String (IP address or CIDR)</td>
|
||
<td>None</td>
|
||
<td>Destination IP address or CIDR.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>source_port</td>
|
||
<td>Integer or String (either as a single port number
|
||
or in the format of a ':' separated range) </td>
|
||
<td>None</td>
|
||
<td>Source port number or a range.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>destination_port</td>
|
||
<td>Integer or String (either as a single port number
|
||
or in the format of a ':' separated range) </td>
|
||
<td>None</td>
|
||
<td>Destination port number or a range.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>position</td>
|
||
<td>Integer</td>
|
||
<td>None</td>
|
||
<td>This is a readonly attribute that gets assigned
|
||
to this rule when the rule is assocated with
|
||
a Firewall Policy. It indicates the position of
|
||
this rule in that Firewall Policy.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>action</td>
|
||
<td>String</td>
|
||
<td>deny</td>
|
||
<td>Action to be performed on the traffic matching
|
||
the rule (allow, deny).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>enabled</td>
|
||
<td>Boolean</td>
|
||
<td>True</td>
|
||
<td>When set to False will disable this rule in the
|
||
Firewall Policy. Facilitates selectively turning
|
||
off rules without having to disassociate the rule
|
||
from the Firewall Policy.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<table rules="all">
|
||
<caption>Firewall Policies</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the firewall policy.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the Firewall Policy. Only
|
||
admin users can specify a tenant_id other
|
||
their own.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>name</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human readable name for the Firewall Policy
|
||
(255 characters limit).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>description</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human readable description for the Firewall Policy
|
||
(1024 characters limit).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>shared</td>
|
||
<td>Boolean</td>
|
||
<td>False</td>
|
||
<td>When set to True makes this Firewall Policy visible
|
||
to tenants other than its owner, and can be used
|
||
to associate with Firewalls not owned by its
|
||
tenant.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>firewall_rules</td>
|
||
<td>List of uuid-str or None</td>
|
||
<td>None</td>
|
||
<td>This is an ordered list of Firewall Rule uuids.
|
||
The Firewall applies the rules in the order in
|
||
which they appear in this list.
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td>audited</td>
|
||
<td>Boolean</td>
|
||
<td>False</td>
|
||
<td>When set to True by the policy owner indicates
|
||
that the Firewall Policy has been audited.This
|
||
attribute is meant to aid in the firewall
|
||
policy audit workflows. Each time the Firewall
|
||
Policy or the associated Firewall Rules are
|
||
changed, this attribute will be set to False and
|
||
will have to be explicitly set to True through an
|
||
update operation.
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<table rules="all">
|
||
<caption>Firewalls</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the firewall.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>Owner of the Firewall. Only admin users can
|
||
specify a tenant_id other than its own.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>name</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human readable name for the Firewall
|
||
(255 characters limit).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>description</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Human readable description for the Firewall
|
||
(1024 characters limit).</td>
|
||
</tr>
|
||
<tr>
|
||
<td>admin_state_up</td>
|
||
<td>Boolean</td>
|
||
<td>True</td>
|
||
<td>The administrative state of the Firewall. If False
|
||
(down), the Firewall does not forward any
|
||
packets.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>status</td>
|
||
<td>String</td>
|
||
<td>N/A </td>
|
||
<td><para>Indicates whether the Firewall is
|
||
currently operational. Possible values
|
||
include: <itemizedlist>
|
||
<listitem>
|
||
<para>ACTIVE</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>DOWN</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>PENDING_CREATE</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>PENDING_UPDATE</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>PENDING_DELETE</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>ERROR</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</para></td>
|
||
</tr>
|
||
<tr>
|
||
<td>firewall_policy_id</td>
|
||
<td>uuid-str or None</td>
|
||
<td>None</td>
|
||
<td>The Firewall Policy uuid that this Firewall
|
||
is associated with. This Firewall will implement
|
||
the rules contained in the Firewall Policy
|
||
represented by this uuid.
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
<section xml:id="fwaas_workflow">
|
||
<title>Common operations in Firewall-as-a-Service Workflow</title>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Create a firewall rule:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron firewall-rule-create --protocol <tcp|udp|icmp|any> --destination-port <port-range> --action <allow|deny></userinput></screen>
|
||
<para>The CLI requires that a protocol value be provided. If
|
||
the rule is protocol agnostic, the 'any' value can be used.
|
||
</para>
|
||
<para>In addition to the protocol attribute, other attributes
|
||
can be specified in the Firewall Rule. Please check the previous
|
||
section for the supported attributes.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Create a firewall policy:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron firewall-policy-create --firewall-rules "<firewall-rule ids or names separated by space>" myfirewallpolicy</userinput></screen>
|
||
<para>The order of the rules specified above is important.
|
||
A firewall policy can be created without any rules and rules
|
||
can be added later either via the update operation (if adding
|
||
multiple rules) or via the insert-rule operation (if adding
|
||
a single rule). Please check the CLI help for more details
|
||
on these operations.</para>
|
||
<note><para>The reference implementation always adds a default
|
||
deny all rule at the end of each policy. This implies that if
|
||
a firewall policy is created without any rules and is associated
|
||
with a firewall, that firewall will block all traffic.</para>
|
||
</note>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Create a firewall:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron firewall-create <firewall-policy-uuid></userinput></screen>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<note>
|
||
<para>The FWaaS features and the above workflow can
|
||
also be accessed from the Horizon user interface. This support is
|
||
disabled by default, but can be enabled by configuring
|
||
<filename>$HORIZON_DIR/openstack_dashboard/local/local_settings.py
|
||
</filename> and setting
|
||
<programlisting language="ini">
|
||
'enable_firewall' = True
|
||
</programlisting>
|
||
</para>
|
||
</note>
|
||
</section>
|
||
</section>
|
||
<section xml:id="allowed_address_pairs">
|
||
<title>Allowed-Address-Pairs</title>
|
||
<para>Allowed-Address-Pairs is an API extension that extends
|
||
the port attribute. This extension allows one to specify
|
||
arbitrary mac_address/ip_address(cidr) pairs that are
|
||
allowed to pass through a port regardless of subnet. The
|
||
main use case for this is to enable the ability to use
|
||
protocols such as VRRP which floats an ip address between
|
||
two instances to enable fast data plane failover.</para>
|
||
<note>
|
||
<para>The allowed-address-pairs extension is currently only
|
||
supported by the following plugins: Nicira NVP, OpenvSwitch,
|
||
and ML2.</para>
|
||
</note>
|
||
<section xml:id="allowed_address_pairs_workflow">
|
||
<title>Common Allowed Address Pairs Workflow</title>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Create a port with a specific allowed-address-pairs:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron port-create net1 --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr></userinput></screen>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Update a port adding allowed-address-pairs:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron port-update <subnet-uuid> --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr></userinput></screen>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<note><para>Setting an allowed-address-pair that matches the
|
||
mac_address and ip_address of a port is prevented. This
|
||
is because that would have no effect since traffic
|
||
matching the mac_address and ip_address is already
|
||
allowed to pass through the port.</para></note>
|
||
<note><para>If your plugin implements the port-security extension
|
||
port-security-enabled must be set to True on the port
|
||
in order to have allowed-address-pairs on a port. The reason for this
|
||
is because if port-security-enabled is set to False this allows
|
||
all traffic to be passed through the port thus having
|
||
allowed-address-pairs would have no effect.</para></note>
|
||
</section>
|
||
</section>
|
||
<section xml:id="plugin_specific_extensions">
|
||
<title>Plugin Specific Extensions</title>
|
||
<?dbhtml stop-chunking?>
|
||
<para>Each vendor may choose to implement additional API
|
||
extensions to the core API. This section describes the
|
||
extensions for each plugin.</para>
|
||
<section xml:id="nicira_extensions">
|
||
<title>Nicira NVP Extensions</title>
|
||
<para>The Nicira NVP plugin Extensions</para>
|
||
<section xml:id="nicira_nvp_plugin_qos_extension">
|
||
<title>Nicira NVP QoS Extension</title>
|
||
<para>The Nicira NVP QoS extension rate-limits network
|
||
ports to guarantee a specific amount of bandwidth
|
||
for each port. This extension, by default, is only
|
||
accessible by a tenant with an admin role but is
|
||
configurable through the
|
||
<filename>policy.json</filename> file. To use
|
||
this extension, create a queue and specify the
|
||
min/max bandwidth rates (kbps) and optionally set
|
||
the QoS Marking and DSCP value (if your network
|
||
fabric uses these values to make forwarding
|
||
decisions). Once created, you can associate a
|
||
queue with a network. Then, when ports are created
|
||
on that network they are automatically created and
|
||
associated with the specific queue size that was
|
||
associated with the network. Because one size
|
||
queue for a every port on a network may not be
|
||
optimal, a scaling factor from the nova flavor
|
||
'rxtx_factor' is passed in from OpenStack Compute
|
||
when creating the port to scale the queue.</para>
|
||
<para>Lastly, if you want to set a specific baseline QoS policy for the amount of
|
||
bandwidth a single port can use (unless a network queue is specified with the
|
||
network a port is created on) a default queue can be created in neutron which
|
||
then causes ports created to be associated with a queue of that size times the
|
||
rxtx scaling factor. One thing to note is that after a network queue or default
|
||
queue is specified this will not add queues to ports previously created and will
|
||
only create queues for ports created thereafter.</para>
|
||
<section xml:id="nicira_nvp_qos_api_abstractions">
|
||
<title>Nicira NVP QoS API Abstractions</title>
|
||
<table rules="all">
|
||
<caption>Nicira NVP QoS Attributes</caption>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="20%"/>
|
||
<col width="40%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Attribute name</th>
|
||
<th>Type</th>
|
||
<th>Default Value</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>id</td>
|
||
<td>uuid-str</td>
|
||
<td>generated</td>
|
||
<td>UUID for the QoS queue.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>default</td>
|
||
<td>Boolean</td>
|
||
<td>False by default</td>
|
||
<td>If True ports will be created with
|
||
this queue size unless the network
|
||
port is created or associated with
|
||
a queue at port creation time.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>name</td>
|
||
<td>String</td>
|
||
<td>None</td>
|
||
<td>Name for QoS queue.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>min</td>
|
||
<td>Integer</td>
|
||
<td>0</td>
|
||
<td>Minimum Bandwidth Rate (kbps).
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td>max</td>
|
||
<td>Integer</td>
|
||
<td>N/A</td>
|
||
<td>Maximum Bandwidth Rate (kbps).
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td>qos_marking</td>
|
||
<td>String</td>
|
||
<td>untrusted by default</td>
|
||
<td>Whether QoS marking should be
|
||
trusted or untrusted.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>dscp</td>
|
||
<td>Integer</td>
|
||
<td>0</td>
|
||
<td>DSCP Marking value.</td>
|
||
</tr>
|
||
<tr>
|
||
<td>tenant_id</td>
|
||
<td>uuid-str</td>
|
||
<td>N/A</td>
|
||
<td>The owner of the QoS queue.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
<section xml:id="nicira_nvp_qos_walk_through">
|
||
<title>Nicira NVP QoS Walk Through</title>
|
||
<para>Create QoS Queue (admin-only)</para>
|
||
<screen><computeroutput>neutron queue-create--min 10 --max 1000 myqueue</computeroutput></screen>
|
||
<para>Associate queue with a network</para>
|
||
<screen><computeroutput>neutron net-create network --queue_id=<queue_id></computeroutput></screen>
|
||
<para>Create default system queue</para>
|
||
<screen><computeroutput>neutron queue-create --default True --min 10 --max 2000 default</computeroutput></screen>
|
||
<para>List QoS Queues:</para>
|
||
<screen><computeroutput>neutron queue-list</computeroutput></screen>
|
||
<para>Delete QoS Queue:</para>
|
||
<screen><computeroutput>neutron queue-delete <queue_id or name>'</computeroutput></screen>
|
||
</section>
|
||
</section>
|
||
<section xml:id="nicira_nvp_provider_extension">
|
||
<title>Nicira NVP provider networks extension</title>
|
||
<para>Provider networks can be implemented in different ways by
|
||
the underlying NVP platform.</para>
|
||
<para>The <emphasis>FLAT</emphasis> and
|
||
<emphasis>VLAN</emphasis> network types use
|
||
bridged transport connectors. These network types
|
||
enable the attachment of large number of ports. To
|
||
handle the increased scale, the NVP plug-in can
|
||
back a single Openstack Network with a chain of
|
||
NVP logical switches. You can specify the maximum
|
||
number of ports on each logical switch in this
|
||
chain on the
|
||
<literal>max_lp_per_bridged_ls</literal>
|
||
parameter, which has a default value of
|
||
5,000.</para>
|
||
<para>The recommended value for this parameter varies with the
|
||
NVP version running in the backend, as shown in the
|
||
following table.</para>
|
||
<para>
|
||
<table rules="all">
|
||
<caption>Recommended values for max_lp_per_bridged_ls</caption>
|
||
<col width="50%"/>
|
||
<col width="50%"/>
|
||
<thead>
|
||
<tr>
|
||
<td>NVP version</td>
|
||
<td>Recommended Value</td>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>2.x</td>
|
||
<td>64</td>
|
||
</tr>
|
||
<tr>
|
||
<td>3.0.x</td>
|
||
<td>5,000</td>
|
||
</tr>
|
||
<tr>
|
||
<td>3.1.x</td>
|
||
<td>5,000</td>
|
||
</tr>
|
||
<tr>
|
||
<td>3.2.x</td>
|
||
<td>10,000</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</para>
|
||
<para>In addition to the above network types, the NVP
|
||
plug-in also supports a special
|
||
<emphasis>l3_ext</emphasis> network type,
|
||
which maps external networks to specific NVP
|
||
gateway services as discussed in the following
|
||
section.</para>
|
||
</section>
|
||
<section xml:id="nicira_nvp_plugin_l3_extension">
|
||
<title>Nicira NVP L3 Extension</title>
|
||
<para>NVP exposes its L3 capabilities through gateway
|
||
services which are usually configured out of band
|
||
from OpenStack. To use NVP with L3 capabilities,
|
||
first create a L3 gateway service in the NVP
|
||
Manager. Next, in <filename>
|
||
/etc/neutron/plugins/nicira/nvp.ini</filename>
|
||
set <literal>default_l3_gw_service_uuid</literal>
|
||
to this value. Now, when routers are created they
|
||
will by default be mapped to this gateway
|
||
service.</para>
|
||
<section xml:id="nicira_l3_walk_through">
|
||
<title>Nicira NVP L3 Extension Walk Through</title>
|
||
<para>Create external network and map it to a specific NVP gateway service:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-create public --router:external=True --provider:network_type l3_ext \
|
||
--provider:physical_network <L3-Gateway-Service-UUID></userinput></screen>
|
||
<para>Terminate traffic on a specific VLAN from a NVP gateway service:</para>
|
||
<screen><prompt>$</prompt> <userinput>neutron net-create public --router:external=True --provider:network_type l3_ext \
|
||
--provider:physical_network <L3-Gateway-Service-UUID> -provider:segmentation_id <VLAN_ID></userinput></screen>
|
||
</section>
|
||
</section>
|
||
</section>
|
||
</section>
|
||
</chapter>
|