docs: Remove archives
This is 99% obsolete / duplicate / confusing information. Change-Id: Ibabb2c0856bd97a0363ad35f576844f9f7947dd0
This commit is contained in:
Ihar Hrachyshka
@@ -1,57 +0,0 @@
|
|||||||
==============================
|
|
||||||
Advanced configuration options
|
|
||||||
==============================
|
|
||||||
|
|
||||||
This section describes advanced configuration options for various system
|
|
||||||
components. For example, configuration options where the default works
|
|
||||||
but that the user wants to customize options. After installing from
|
|
||||||
packages, ``$NEUTRON_CONF_DIR`` is ``/etc/neutron``.
|
|
||||||
|
|
||||||
L3 metering agent
|
|
||||||
~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
You can run an L3 metering agent that enables layer-3 traffic metering.
|
|
||||||
In general, you should launch the metering agent on all nodes that run
|
|
||||||
the L3 agent:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ neutron-metering-agent --config-file NEUTRON_CONFIG_FILE \
|
|
||||||
--config-file L3_METERING_CONFIG_FILE
|
|
||||||
|
|
||||||
You must configure a driver that matches the plug-in that runs on the
|
|
||||||
service. The driver adds metering to the routing interface.
|
|
||||||
|
|
||||||
+------------------------------------------+---------------------------------+
|
|
||||||
| Option | Value |
|
|
||||||
+==========================================+=================================+
|
|
||||||
| **Open vSwitch** | |
|
|
||||||
+------------------------------------------+---------------------------------+
|
|
||||||
| interface\_driver | |
|
|
||||||
| ($NEUTRON\_CONF\_DIR/metering\_agent.ini)| openvswitch |
|
|
||||||
+------------------------------------------+---------------------------------+
|
|
||||||
| **Linux Bridge** | |
|
|
||||||
+------------------------------------------+---------------------------------+
|
|
||||||
| interface\_driver | |
|
|
||||||
| ($NEUTRON\_CONF\_DIR/metering\_agent.ini)| linuxbridge |
|
|
||||||
+------------------------------------------+---------------------------------+
|
|
||||||
|
|
||||||
L3 metering driver
|
|
||||||
------------------
|
|
||||||
|
|
||||||
You must configure any driver that implements the metering abstraction.
|
|
||||||
Currently the only available implementation uses iptables for metering.
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
driver = iptables
|
|
||||||
|
|
||||||
L3 metering service driver
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
To enable L3 metering, you must set the following option in the
|
|
||||||
``neutron.conf`` file on the host that runs ``neutron-server``:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
service_plugins = metering
|
|
||||||
@@ -1,590 +0,0 @@
|
|||||||
.. _adv-features:
|
|
||||||
|
|
||||||
========================================
|
|
||||||
Advanced features through API extensions
|
|
||||||
========================================
|
|
||||||
|
|
||||||
Several plug-ins implement API extensions that provide capabilities
|
|
||||||
similar to what was available in ``nova-network``. These plug-ins are likely
|
|
||||||
to be of interest to the OpenStack community.
|
|
||||||
|
|
||||||
Provider networks
|
|
||||||
~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Networks can be categorized as either project networks or provider
|
|
||||||
networks. Project networks are created by normal users and details about
|
|
||||||
how they are physically realized are hidden from those users. Provider
|
|
||||||
networks are created with administrative credentials, specifying the
|
|
||||||
details of how the network is physically realized, usually to match some
|
|
||||||
existing network in the data center.
|
|
||||||
|
|
||||||
Provider networks enable administrators to create networks that map
|
|
||||||
directly to the physical networks in the data center.
|
|
||||||
This is commonly used to give projects direct access to a public network
|
|
||||||
that can be used to reach the Internet. It might also be used to
|
|
||||||
integrate with VLANs in the network that already have a defined meaning
|
|
||||||
(for example, enable a VM from the marketing department to be placed
|
|
||||||
on the same VLAN as bare-metal marketing hosts in the same data center).
|
|
||||||
|
|
||||||
The provider extension allows administrators to explicitly manage the
|
|
||||||
relationship between Networking virtual networks and underlying physical
|
|
||||||
mechanisms such as VLANs and tunnels. When this extension is supported,
|
|
||||||
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.
|
|
||||||
|
|
||||||
The provider extension is supported by the Open vSwitch and Linux Bridge
|
|
||||||
plug-ins. Configuration of these plug-ins requires familiarity with this
|
|
||||||
extension.
|
|
||||||
|
|
||||||
Terminology
|
|
||||||
-----------
|
|
||||||
|
|
||||||
A number of terms are used in the provider extension and in the
|
|
||||||
configuration of plug-ins supporting the provider extension:
|
|
||||||
|
|
||||||
.. list-table:: **Provider extension terminology**
|
|
||||||
:widths: 30 70
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Term
|
|
||||||
- Description
|
|
||||||
* - virtual network
|
|
||||||
- A Networking L2 network (identified by a UUID and optional name) whose
|
|
||||||
ports can be attached as vNICs to Compute instances and to various
|
|
||||||
Networking agents. The Open vSwitch and Linux Bridge plug-ins each
|
|
||||||
support several different mechanisms to realize virtual networks.
|
|
||||||
* - physical network
|
|
||||||
- A network connecting virtualization hosts (such as compute nodes) with
|
|
||||||
each other and with other network resources. Each physical network might
|
|
||||||
support multiple virtual networks. The provider extension and the plug-in
|
|
||||||
configurations identify physical networks using simple string names.
|
|
||||||
* - project network
|
|
||||||
- A virtual network that a project or an administrator creates. The
|
|
||||||
physical details of the network are not exposed to the project.
|
|
||||||
* - provider network
|
|
||||||
- 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. Project can be given access to provider
|
|
||||||
networks.
|
|
||||||
* - VLAN network
|
|
||||||
- A virtual network implemented 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.
|
|
||||||
* - flat network
|
|
||||||
- A virtual network implemented as packets on a specific physical network
|
|
||||||
containing no IEEE 802.1Q header. Each physical network can realize at
|
|
||||||
most one flat network.
|
|
||||||
* - local network
|
|
||||||
- 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 can have other uses.
|
|
||||||
* - GRE network
|
|
||||||
- A virtual network implemented as network packets encapsulated using
|
|
||||||
GRE. GRE networks are also referred to as *tunnels*. GRE tunnel packets
|
|
||||||
are routed by the IP routing table for the host, so GRE networks are not
|
|
||||||
associated by Networking with specific physical networks.
|
|
||||||
* - Virtual Extensible LAN (VXLAN) network
|
|
||||||
- VXLAN is a proposed encapsulation protocol for running an overlay network
|
|
||||||
on existing Layer 3 infrastructure. An overlay network is a virtual
|
|
||||||
network that is built on top of existing network Layer 2 and Layer 3
|
|
||||||
technologies to support elastic compute architectures.
|
|
||||||
|
|
||||||
The ML2, Open vSwitch, and Linux Bridge plug-ins support VLAN networks,
|
|
||||||
flat networks, and local networks. Only the ML2 and Open vSwitch
|
|
||||||
plug-ins currently support GRE and VXLAN networks, provided that the
|
|
||||||
required features exist in the hosts Linux kernel, Open vSwitch, and
|
|
||||||
iproute2 packages.
|
|
||||||
|
|
||||||
Provider attributes
|
|
||||||
-------------------
|
|
||||||
|
|
||||||
The provider extension extends the Networking network resource with
|
|
||||||
these attributes:
|
|
||||||
|
|
||||||
|
|
||||||
.. list-table:: **Provider network attributes**
|
|
||||||
:widths: 10 10 10 49
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Attribute name
|
|
||||||
- Type
|
|
||||||
- Default Value
|
|
||||||
- Description
|
|
||||||
* - provider: network\_type
|
|
||||||
- String
|
|
||||||
- N/A
|
|
||||||
- The physical mechanism by which the virtual network is implemented.
|
|
||||||
Possible values are ``flat``, ``vlan``, ``local``, ``gre``, and
|
|
||||||
``vxlan``, corresponding to flat networks, VLAN networks, local
|
|
||||||
networks, GRE networks, and VXLAN networks as defined above.
|
|
||||||
All types of provider networks can be created by administrators,
|
|
||||||
while project networks can be implemented as ``vlan``, ``gre``,
|
|
||||||
``vxlan``, or ``local`` network types depending on plug-in
|
|
||||||
configuration.
|
|
||||||
* - provider: physical_network
|
|
||||||
- String
|
|
||||||
- If a physical network named "default" has been configured and
|
|
||||||
if provider:network_type is ``flat`` or ``vlan``, then "default"
|
|
||||||
is used.
|
|
||||||
- The name of the physical network over which the virtual network
|
|
||||||
is implemented for flat and VLAN networks. Not applicable to the
|
|
||||||
``local``, ``vxlan`` or ``gre`` network types.
|
|
||||||
* - provider:segmentation_id
|
|
||||||
- Integer
|
|
||||||
- N/A
|
|
||||||
- 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.
|
|
||||||
|
|
||||||
To view or set provider extended attributes, a client must be authorized
|
|
||||||
for the ``extension:provider_network:view`` and
|
|
||||||
``extension:provider_network:set`` actions in the Networking policy
|
|
||||||
configuration. The default Networking configuration authorizes both
|
|
||||||
actions for users with the admin role. An authorized client or an
|
|
||||||
administrative user can view and set the provider extended attributes
|
|
||||||
through Networking API calls. See the section called
|
|
||||||
:ref:`Authentication and authorization` for details on policy configuration.
|
|
||||||
|
|
||||||
.. _L3-routing-and-NAT:
|
|
||||||
|
|
||||||
L3 routing and NAT
|
|
||||||
~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The Networking API provides abstract L2 network segments that are
|
|
||||||
decoupled from the technology used to implement the L2 network.
|
|
||||||
Networking includes an API extension that provides abstract L3 routers
|
|
||||||
that API users can dynamically provision and configure. These Networking
|
|
||||||
routers can connect multiple L2 Networking networks and can also provide
|
|
||||||
a gateway that connects one or more private L2 networks to a shared
|
|
||||||
external network. For example, a public network for access to the
|
|
||||||
Internet. See the `OpenStack Configuration Reference <https://docs.
|
|
||||||
openstack.org/ocata/config-reference/>`_ for details on common
|
|
||||||
models of deploying Networking L3 routers.
|
|
||||||
|
|
||||||
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 project to
|
|
||||||
selectively expose VMs on private networks to other hosts on the
|
|
||||||
external network (and often to all hosts on the Internet). You can
|
|
||||||
allocate and map floating IPs from one port to another, as needed.
|
|
||||||
|
|
||||||
Basic L3 operations
|
|
||||||
-------------------
|
|
||||||
|
|
||||||
External networks are visible to all users. However, the default policy
|
|
||||||
settings enable only administrative users to create, update, and delete
|
|
||||||
external networks.
|
|
||||||
|
|
||||||
This table shows example :command:`openstack` commands that enable you
|
|
||||||
to complete basic L3 operations:
|
|
||||||
|
|
||||||
.. list-table:: **Basic L3 Operations**
|
|
||||||
:widths: 30 50
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Operation
|
|
||||||
- Command
|
|
||||||
* - Creates external networks.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network create public --external
|
|
||||||
$ openstack subnet create --network public --subnet-range 172.16.1.0/24 subnetname
|
|
||||||
* - Lists external networks.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network list --external
|
|
||||||
* - Creates an internal-only router that connects to multiple L2 networks privately.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network create net1
|
|
||||||
$ openstack subnet create --network net1 --subnet-range 10.0.0.0/24 subnetname1
|
|
||||||
$ openstack network create net2
|
|
||||||
$ openstack subnet create --network net2 --subnet-range 10.0.1.0/24 subnetname2
|
|
||||||
$ openstack router create router1
|
|
||||||
$ openstack router add subnet router1 subnetname1
|
|
||||||
$ openstack router add subnet router1 subnetname2
|
|
||||||
|
|
||||||
An internal router port can have only one IPv4 subnet and multiple IPv6 subnets
|
|
||||||
that belong to the same network ID. When you call ``router-interface-add`` with an IPv6
|
|
||||||
subnet, this operation adds the interface to an existing internal port with the same
|
|
||||||
network ID. If a port with the same network ID does not exist, a new port is created.
|
|
||||||
|
|
||||||
* - Connects a router to an external network, which enables that router to
|
|
||||||
act as a NAT gateway for external connectivity.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack router set --external-gateway EXT_NET_ID router1
|
|
||||||
$ openstack router set --route destination=172.24.4.0/24,gateway=172.24.4.1 router1
|
|
||||||
|
|
||||||
The router obtains an interface with the gateway_ip address of the
|
|
||||||
subnet and this interface is attached to a port on the L2 Networking
|
|
||||||
network associated with the subnet. The router also gets a gateway
|
|
||||||
interface to the specified external network. This provides SNAT
|
|
||||||
connectivity to the external network as well as support for floating
|
|
||||||
IPs allocated on that external networks. Commonly an external network
|
|
||||||
maps to a network in the provider.
|
|
||||||
|
|
||||||
* - Lists routers.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack router list
|
|
||||||
* - Shows information for a specified router.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack router show ROUTER_ID
|
|
||||||
* - Shows all internal interfaces for a router.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack port list --router ROUTER_ID
|
|
||||||
$ openstack port list --router ROUTER_NAME
|
|
||||||
* - Identifies the PORT_ID that represents the VM NIC to which the floating
|
|
||||||
IP should map.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack port list -c ID -c "Fixed IP Addresses" --server INSTANCE_ID
|
|
||||||
|
|
||||||
This port must be on a Networking subnet that is attached to
|
|
||||||
a router uplinked to the external network 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).
|
|
||||||
|
|
||||||
* - Creates a floating IP address and associates it with a port.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip create EXT_NET_ID
|
|
||||||
$ openstack floating ip add port FLOATING_IP_ID --port-id INTERNAL_VM_PORT_ID
|
|
||||||
|
|
||||||
* - Creates a floating IP on a specific subnet in the external network.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip create EXT_NET_ID --subnet SUBNET_ID
|
|
||||||
|
|
||||||
If there are multiple subnets in the external network, you can choose a specific
|
|
||||||
subnet based on quality and costs.
|
|
||||||
|
|
||||||
* - Creates a floating IP address and associates it with a port, in a single step.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip create --port INTERNAL_VM_PORT_ID EXT_NET_ID
|
|
||||||
* - Lists floating IPs
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip list
|
|
||||||
* - Finds floating IP for a specified VM port.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip list --port INTERNAL_VM_PORT_ID
|
|
||||||
* - Disassociates a floating IP address.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip remove port FLOATING_IP_ID
|
|
||||||
* - Deletes the floating IP address.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack floating ip delete FLOATING_IP_ID
|
|
||||||
* - Clears the gateway.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack router unset --external-gateway router1
|
|
||||||
* - Removes the interfaces from the router.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack router remove subnet router1 SUBNET_ID
|
|
||||||
|
|
||||||
If this subnet ID is the last subnet on the port, this operation deletes the port itself.
|
|
||||||
|
|
||||||
* - Deletes the router.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack router delete router1
|
|
||||||
|
|
||||||
Security groups
|
|
||||||
~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Security groups and security group rules allow administrators and
|
|
||||||
projects 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 in Networking 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.
|
|
||||||
|
|
||||||
To use the Compute security group APIs or use Compute to orchestrate the
|
|
||||||
creation of ports for instances on specific security groups, you must
|
|
||||||
complete additional configuration. You must configure the
|
|
||||||
``/etc/nova/nova.conf`` file and set the ``use_neutron=True``
|
|
||||||
option on every node that runs nova-compute, nova-conductor and nova-api.
|
|
||||||
After you make this change, restart those nova services to pick up this change.
|
|
||||||
Then, you can use both the Compute and OpenStack Network security group
|
|
||||||
APIs at the same time.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
- To use the Compute security group API with Networking, the
|
|
||||||
Networking plug-in must implement the security group API. The
|
|
||||||
following plug-ins currently implement this: ML2, Open vSwitch,
|
|
||||||
Linux Bridge, NEC, and VMware NSX.
|
|
||||||
|
|
||||||
- You must configure the correct firewall driver in the
|
|
||||||
``securitygroup`` section of the plug-in/agent configuration
|
|
||||||
file. Some plug-ins 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.
|
|
||||||
|
|
||||||
- When using the security group API through Compute, security
|
|
||||||
groups are applied to all ports on an instance. The reason for
|
|
||||||
this is that Compute security group APIs are instances based and
|
|
||||||
not port based as Networking.
|
|
||||||
|
|
||||||
- When creating or updating a port with a specified security group,
|
|
||||||
the admin tenant can use the security groups of other tenants.
|
|
||||||
|
|
||||||
Basic security group operations
|
|
||||||
-------------------------------
|
|
||||||
|
|
||||||
This table shows example neutron commands that enable you to complete
|
|
||||||
basic security group operations:
|
|
||||||
|
|
||||||
.. list-table:: **Basic security group operations**
|
|
||||||
:widths: 30 50
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Operation
|
|
||||||
- Command
|
|
||||||
* - Creates a security group for our web servers.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group create webservers \
|
|
||||||
--description "security group for webservers"
|
|
||||||
* - Lists security groups.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group list
|
|
||||||
* - Creates a security group rule to allow port 80 ingress.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group rule create --ingress \
|
|
||||||
--protocol tcp SECURITY_GROUP_UUID
|
|
||||||
* - Lists security group rules.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group rule list
|
|
||||||
* - Deletes a security group rule.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group rule delete SECURITY_GROUP_RULE_UUID
|
|
||||||
* - Deletes a security group.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group delete SECURITY_GROUP_UUID
|
|
||||||
* - Creates a port and associates two security groups.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack port create port1 --security-group SECURITY_GROUP_ID1 \
|
|
||||||
--security-group SECURITY_GROUP_ID2 --network NETWORK_ID
|
|
||||||
* - Removes security groups from a port.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack port set --no-security-group PORT_ID
|
|
||||||
|
|
||||||
Plug-in specific extensions
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Each vendor can choose to implement additional API extensions to the
|
|
||||||
core API. This section describes the extensions for each plug-in.
|
|
||||||
|
|
||||||
Big Switch plug-in extensions
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
This section explains the Big Switch neutron plug-in-specific extension.
|
|
||||||
|
|
||||||
Big Switch router rules
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
Big Switch allows router rules to be added to each project router. These
|
|
||||||
rules can be used to enforce routing policies such as denying traffic
|
|
||||||
between subnets or traffic to external networks. By enforcing these at
|
|
||||||
the router level, network segmentation policies can be enforced across
|
|
||||||
many VMs that have differing security groups.
|
|
||||||
|
|
||||||
Router rule attributes
|
|
||||||
''''''''''''''''''''''
|
|
||||||
|
|
||||||
Each project router has a set of router rules associated with it. Each
|
|
||||||
router rule has the attributes in this table. Router rules and their
|
|
||||||
attributes can be set using the :command:`neutron router-update` command,
|
|
||||||
through the horizon interface or the Networking API.
|
|
||||||
|
|
||||||
.. list-table:: **Big Switch Router rule attributes**
|
|
||||||
:widths: 10 10 10 35
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Attribute name
|
|
||||||
- Required
|
|
||||||
- Input type
|
|
||||||
- Description
|
|
||||||
* - source
|
|
||||||
- Yes
|
|
||||||
- A valid CIDR or one of the keywords 'any' or 'external'
|
|
||||||
- The network that a packet's source IP must match for the
|
|
||||||
rule to be applied.
|
|
||||||
* - destination
|
|
||||||
- Yes
|
|
||||||
- A valid CIDR or one of the keywords 'any' or 'external'
|
|
||||||
- The network that a packet's destination IP must match for the rule to
|
|
||||||
be applied.
|
|
||||||
* - action
|
|
||||||
- Yes
|
|
||||||
- 'permit' or 'deny'
|
|
||||||
- Determines whether or not the matched packets will allowed to cross the
|
|
||||||
router.
|
|
||||||
* - nexthop
|
|
||||||
- No
|
|
||||||
- A plus-separated (+) list of next-hop IP addresses. For example,
|
|
||||||
``1.1.1.1+1.1.1.2``.
|
|
||||||
- Overrides the default virtual router used to handle traffic for packets
|
|
||||||
that match the rule.
|
|
||||||
|
|
||||||
Order of rule processing
|
|
||||||
''''''''''''''''''''''''
|
|
||||||
|
|
||||||
The order of router rules has no effect. Overlapping rules are evaluated
|
|
||||||
using longest prefix matching on the source and destination fields. The
|
|
||||||
source field is matched first so it always takes higher precedence over
|
|
||||||
the destination field. In other words, longest prefix matching is used
|
|
||||||
on the destination field only if there are multiple matching rules with
|
|
||||||
the same source.
|
|
||||||
|
|
||||||
Big Switch router rules operations
|
|
||||||
''''''''''''''''''''''''''''''''''
|
|
||||||
|
|
||||||
Router rules are configured with a router update operation in OpenStack
|
|
||||||
Networking. The update overrides any previous rules so all rules must be
|
|
||||||
provided at the same time.
|
|
||||||
|
|
||||||
Update a router with rules to permit traffic by default but block
|
|
||||||
traffic from external networks to the 10.10.10.0/24 subnet:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ neutron router-update ROUTER_UUID --router_rules type=dict list=true \
|
|
||||||
source=any,destination=any,action=permit \
|
|
||||||
source=external,destination=10.10.10.0/24,action=deny
|
|
||||||
|
|
||||||
Specify alternate next-hop addresses for a specific subnet:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ neutron router-update ROUTER_UUID --router_rules type=dict list=true \
|
|
||||||
source=any,destination=any,action=permit \
|
|
||||||
source=10.10.10.0/24,destination=any,action=permit,nexthops=10.10.10.254+10.10.10.253
|
|
||||||
|
|
||||||
Block traffic between two subnets while allowing everything else:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ neutron router-update ROUTER_UUID --router_rules type=dict list=true \
|
|
||||||
source=any,destination=any,action=permit \
|
|
||||||
source=10.10.10.0/24,destination=10.20.20.20/24,action=deny
|
|
||||||
|
|
||||||
L3 metering
|
|
||||||
~~~~~~~~~~~
|
|
||||||
|
|
||||||
The L3 metering API extension enables administrators to configure IP
|
|
||||||
ranges and assign a specified label to them to be able to measure
|
|
||||||
traffic that goes through a virtual router.
|
|
||||||
|
|
||||||
The L3 metering extension is decoupled from the technology that
|
|
||||||
implements the measurement. Two abstractions have been added: One is the
|
|
||||||
metering label that can contain metering rules. Because a metering label
|
|
||||||
is associated with a project, all virtual routers in this project are
|
|
||||||
associated with this label.
|
|
||||||
|
|
||||||
Basic L3 metering operations
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
Only administrators can manage the L3 metering labels and rules.
|
|
||||||
|
|
||||||
This table shows example :command:`neutron` commands that enable you to
|
|
||||||
complete basic L3 metering operations:
|
|
||||||
|
|
||||||
.. list-table:: **Basic L3 operations**
|
|
||||||
:widths: 20 50
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Operation
|
|
||||||
- Command
|
|
||||||
* - Creates a metering label.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label create LABEL1 \
|
|
||||||
--description "DESCRIPTION_LABEL1"
|
|
||||||
* - Lists metering labels.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label list
|
|
||||||
* - Shows information for a specified label.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label show LABEL_UUID
|
|
||||||
$ openstack network meter label show LABEL1
|
|
||||||
* - Deletes a metering label.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label delete LABEL_UUID
|
|
||||||
$ openstack network meter label delete LABEL1
|
|
||||||
* - Creates a metering rule.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label rule create LABEL_UUID \
|
|
||||||
--remote-ip-prefix CIDR \
|
|
||||||
--direction DIRECTION --exclude
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label rule create label1 \
|
|
||||||
--remote-ip-prefix 10.0.0.0/24 --direction ingress
|
|
||||||
$ openstack network meter label rule create label1 \
|
|
||||||
--remote-ip-prefix 20.0.0.0/24 --exclude
|
|
||||||
|
|
||||||
* - Lists metering all label rules.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label rule list
|
|
||||||
* - Shows information for a specified label rule.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label rule show RULE_UUID
|
|
||||||
* - Deletes a metering label rule.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network meter label rule delete RULE_UUID
|
|
||||||
* - Lists the value of created metering label rules.
|
|
||||||
- .. code-block:: console
|
|
||||||
|
|
||||||
$ ceilometer sample-list -m SNMP_MEASUREMENT
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ ceilometer sample-list -m hardware.network.bandwidth.bytes
|
|
||||||
$ ceilometer sample-list -m hardware.network.incoming.bytes
|
|
||||||
$ ceilometer sample-list -m hardware.network.outgoing.bytes
|
|
||||||
$ ceilometer sample-list -m hardware.network.outgoing.errors
|
|
||||||
@@ -1,123 +0,0 @@
|
|||||||
=============================
|
|
||||||
Advanced operational features
|
|
||||||
=============================
|
|
||||||
|
|
||||||
Logging settings
|
|
||||||
~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Networking components use Python logging module to do logging. Logging
|
|
||||||
configuration can be provided in ``neutron.conf`` or as command-line
|
|
||||||
options. Command options override ones in ``neutron.conf``.
|
|
||||||
|
|
||||||
To configure logging for Networking components, use one of these
|
|
||||||
methods:
|
|
||||||
|
|
||||||
- Provide logging settings in a logging configuration file.
|
|
||||||
|
|
||||||
See `Python logging
|
|
||||||
how-to <https://docs.python.org/howto/logging.html>`__ to learn more
|
|
||||||
about logging.
|
|
||||||
|
|
||||||
- Provide logging setting in ``neutron.conf``.
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
# Default log level is WARNING
|
|
||||||
# Show debugging output in logs (sets DEBUG log level output)
|
|
||||||
# debug = False
|
|
||||||
|
|
||||||
# log_date_format = %Y-%m-%d %H:%M:%S
|
|
||||||
|
|
||||||
# use_syslog = False
|
|
||||||
# syslog_log_facility = LOG_USER
|
|
||||||
|
|
||||||
# if use_syslog is False, we can set log_file and log_dir.
|
|
||||||
# if use_syslog is False and we do not set log_file,
|
|
||||||
# the log will be printed to stdout.
|
|
||||||
# log_file =
|
|
||||||
# log_dir =
|
|
||||||
|
|
||||||
Notifications
|
|
||||||
~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Notifications can be sent when Networking resources such as network,
|
|
||||||
subnet and port are created, updated or deleted.
|
|
||||||
|
|
||||||
Notification options
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
To support DHCP agent, ``rpc_notifier`` driver must be set. To set up the
|
|
||||||
notification, edit notification options in ``neutron.conf``:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
# Driver or drivers to handle sending notifications. (multi
|
|
||||||
# valued)
|
|
||||||
# notification_driver=messagingv2
|
|
||||||
|
|
||||||
# AMQP topic used for OpenStack notifications. (list value)
|
|
||||||
# Deprecated group/name - [rpc_notifier2]/topics
|
|
||||||
notification_topics = notifications
|
|
||||||
|
|
||||||
Setting cases
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Logging and RPC
|
|
||||||
^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
These options configure the Networking server to send notifications
|
|
||||||
through logging and RPC. The logging options are described in OpenStack
|
|
||||||
Configuration Reference . RPC notifications go to ``notifications.info``
|
|
||||||
queue bound to a topic exchange defined by ``control_exchange`` in
|
|
||||||
``neutron.conf``.
|
|
||||||
|
|
||||||
**Notification System Options**
|
|
||||||
|
|
||||||
A notification can be sent when a network, subnet, or port is created,
|
|
||||||
updated or deleted. The notification system options are:
|
|
||||||
|
|
||||||
* ``notification_driver``
|
|
||||||
Defines the driver or drivers to handle the sending of a notification.
|
|
||||||
The six available options are:
|
|
||||||
|
|
||||||
* ``messaging``
|
|
||||||
Send notifications using the 1.0 message format.
|
|
||||||
* ``messagingv2``
|
|
||||||
Send notifications using the 2.0 message format (with a message
|
|
||||||
envelope).
|
|
||||||
* ``routing``
|
|
||||||
Configurable routing notifier (by priority or event_type).
|
|
||||||
* ``log``
|
|
||||||
Publish notifications using Python logging infrastructure.
|
|
||||||
* ``test``
|
|
||||||
Store notifications in memory for test verification.
|
|
||||||
* ``noop``
|
|
||||||
Disable sending notifications entirely.
|
|
||||||
* ``default_notification_level``
|
|
||||||
Is used to form topic names or to set a logging level.
|
|
||||||
* ``default_publisher_id``
|
|
||||||
Is a part of the notification payload.
|
|
||||||
* ``notification_topics``
|
|
||||||
AMQP topic used for OpenStack notifications. They can be comma-separated
|
|
||||||
values. The actual topic names will be the values of
|
|
||||||
``default_notification_level``.
|
|
||||||
* ``control_exchange``
|
|
||||||
This is an option defined in oslo.messaging. It is the default exchange
|
|
||||||
under which topics are scoped. May be overridden by an exchange name
|
|
||||||
specified in the ``transport_url`` option. It is a string value.
|
|
||||||
|
|
||||||
Below is a sample ``neutron.conf`` configuration file:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
notification_driver = messagingv2
|
|
||||||
|
|
||||||
default_notification_level = INFO
|
|
||||||
|
|
||||||
host = myhost.com
|
|
||||||
default_publisher_id = $host
|
|
||||||
|
|
||||||
notification_topics = notifications
|
|
||||||
|
|
||||||
control_exchange = openstack
|
|
||||||
@@ -1,88 +0,0 @@
|
|||||||
=======================
|
|
||||||
Networking architecture
|
|
||||||
=======================
|
|
||||||
|
|
||||||
Before you deploy Networking, it is useful to understand the Networking
|
|
||||||
services and how they interact with the OpenStack components.
|
|
||||||
|
|
||||||
Overview
|
|
||||||
~~~~~~~~
|
|
||||||
|
|
||||||
Networking is a standalone component in the OpenStack modular
|
|
||||||
architecture. It is positioned alongside OpenStack components such as
|
|
||||||
Compute, Image service, Identity, or Dashboard. Like those
|
|
||||||
components, a deployment of Networking often involves deploying several
|
|
||||||
services to a variety of hosts.
|
|
||||||
|
|
||||||
The Networking server uses the neutron-server daemon to expose the
|
|
||||||
Networking API and enable administration of the configured Networking
|
|
||||||
plug-in. Typically, the plug-in requires access to a database for
|
|
||||||
persistent storage (also similar to other OpenStack services).
|
|
||||||
|
|
||||||
If your deployment uses a controller host to run centralized Compute
|
|
||||||
components, you can deploy the Networking server to that same host.
|
|
||||||
However, Networking is entirely standalone and can be deployed to a
|
|
||||||
dedicated host. Depending on your configuration, Networking can also
|
|
||||||
include the following agents:
|
|
||||||
|
|
||||||
+----------------------------+---------------------------------------------+
|
|
||||||
| Agent | Description |
|
|
||||||
+============================+=============================================+
|
|
||||||
|**plug-in agent** | |
|
|
||||||
|(``neutron-*-agent``) | Runs on each hypervisor to perform |
|
|
||||||
| | local vSwitch configuration. The agent that |
|
|
||||||
| | runs, depends on the plug-in that you use. |
|
|
||||||
| | Certain plug-ins do not require an agent. |
|
|
||||||
+----------------------------+---------------------------------------------+
|
|
||||||
|**dhcp agent** | |
|
|
||||||
|(``neutron-dhcp-agent``) | Provides DHCP services to project networks. |
|
|
||||||
| | Required by certain plug-ins. |
|
|
||||||
+----------------------------+---------------------------------------------+
|
|
||||||
|**l3 agent** | |
|
|
||||||
|(``neutron-l3-agent``) | Provides L3/NAT forwarding to provide |
|
|
||||||
| | external network access for VMs on project |
|
|
||||||
| | networks. Required by certain plug-ins. |
|
|
||||||
+----------------------------+---------------------------------------------+
|
|
||||||
|**metering agent** | |
|
|
||||||
|(``neutron-metering-agent``)| Provides L3 traffic metering for project |
|
|
||||||
| | networks. |
|
|
||||||
+----------------------------+---------------------------------------------+
|
|
||||||
|
|
||||||
These agents interact with the main neutron process through RPC (for
|
|
||||||
example, RabbitMQ or Qpid) or through the standard Networking API. In
|
|
||||||
addition, Networking integrates with OpenStack components in a number of
|
|
||||||
ways:
|
|
||||||
|
|
||||||
- Networking relies on the Identity service (keystone) for the
|
|
||||||
authentication and authorization of all API requests.
|
|
||||||
|
|
||||||
- Compute (nova) interacts with Networking through calls to its
|
|
||||||
standard API. As part of creating a VM, the ``nova-compute`` service
|
|
||||||
communicates with the Networking API to plug each virtual NIC on the
|
|
||||||
VM into a particular network.
|
|
||||||
|
|
||||||
- The dashboard (horizon) integrates with the Networking API, enabling
|
|
||||||
administrators and project users to create and manage network services
|
|
||||||
through a web-based GUI.
|
|
||||||
|
|
||||||
VMware NSX integration
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
OpenStack Networking uses the NSX plug-in to integrate with an existing
|
|
||||||
VMware vCenter deployment. When installed on the network nodes, the NSX
|
|
||||||
plug-in enables a NSX controller to centrally manage configuration
|
|
||||||
settings and push them to managed network nodes. Network nodes are
|
|
||||||
considered managed when they are added as hypervisors to the NSX
|
|
||||||
controller.
|
|
||||||
|
|
||||||
The diagrams below depict some VMware NSX deployment examples. The first
|
|
||||||
diagram illustrates the traffic flow between VMs on separate Compute
|
|
||||||
nodes, and the second diagram between two VMs on a single compute node.
|
|
||||||
Note the placement of the VMware NSX plug-in and the neutron-server
|
|
||||||
service on the network node. The green arrow indicates the management
|
|
||||||
relationship between the NSX controller and the network node.
|
|
||||||
|
|
||||||
|
|
||||||
.. figure:: figures/vmware_nsx_ex1.png
|
|
||||||
|
|
||||||
.. figure:: figures/vmware_nsx_ex2.png
|
|
||||||
@@ -1,165 +0,0 @@
|
|||||||
.. _Authentication and authorization:
|
|
||||||
|
|
||||||
================================
|
|
||||||
Authentication and authorization
|
|
||||||
================================
|
|
||||||
|
|
||||||
Networking uses the Identity service as the default authentication
|
|
||||||
service. When the Identity service is enabled, users who submit requests
|
|
||||||
to the Networking service must provide an authentication token in
|
|
||||||
``X-Auth-Token`` request header. Users obtain this token by
|
|
||||||
authenticating with the Identity service endpoint. For more information
|
|
||||||
about authentication with the Identity service, see `OpenStack Identity
|
|
||||||
service API v3
|
|
||||||
Reference <https://docs.openstack.org/api-ref/identity/v3/>`__.
|
|
||||||
When the Identity service is enabled, it is not mandatory to specify the
|
|
||||||
project ID for resources in create requests because the project ID is
|
|
||||||
derived from the authentication token.
|
|
||||||
|
|
||||||
The default authorization settings only allow administrative users
|
|
||||||
to create resources on behalf of a different project. Networking uses
|
|
||||||
information received from Identity to authorize user requests.
|
|
||||||
Networking handles two kind of authorization policies:
|
|
||||||
|
|
||||||
- **Operation-based** policies specify access criteria for specific
|
|
||||||
operations, possibly with fine-grained control over specific
|
|
||||||
attributes.
|
|
||||||
|
|
||||||
- **Resource-based** policies specify whether access to specific
|
|
||||||
resource is granted or not according to the permissions configured
|
|
||||||
for the resource (currently available only for the network resource).
|
|
||||||
The actual authorization policies enforced in Networking might vary
|
|
||||||
from deployment to deployment.
|
|
||||||
|
|
||||||
The policy engine reads entries from the ``policy.yaml`` file. The
|
|
||||||
actual location of this file might vary from distribution to
|
|
||||||
distribution. Entries can be updated while the system is running, and no
|
|
||||||
service restart is required. Every time the policy file is updated, the
|
|
||||||
policies are automatically reloaded. Currently the only way of updating
|
|
||||||
such policies is to edit the policy file. In this section, the terms
|
|
||||||
*policy* and *rule* refer to objects that are specified in the same way
|
|
||||||
in the policy file. There are no syntax differences between a rule and a
|
|
||||||
policy. A policy is something that is matched directly from the
|
|
||||||
Networking policy engine. A rule is an element in a policy, which is
|
|
||||||
evaluated. For instance in ``"create_subnet":
|
|
||||||
"rule:admin_or_network_owner"``, *create_subnet* is a
|
|
||||||
policy, and *admin_or_network_owner* is a rule.
|
|
||||||
|
|
||||||
Policies are triggered by the Networking policy engine whenever one of
|
|
||||||
them matches a Networking API operation or a specific attribute being
|
|
||||||
used in a given operation. For instance the ``create_subnet`` policy is
|
|
||||||
triggered every time a ``POST /v2.0/subnets`` request is sent to the
|
|
||||||
Networking server; on the other hand ``create_network:shared`` is
|
|
||||||
triggered every time the *shared* attribute is explicitly specified (and
|
|
||||||
set to a value different from its default) in a ``POST /v2.0/networks``
|
|
||||||
request. It is also worth mentioning that policies can also be related
|
|
||||||
to specific API extensions; for instance
|
|
||||||
``extension:provider_network:set`` is triggered if the attributes
|
|
||||||
defined by the Provider Network extensions are specified in an API
|
|
||||||
request.
|
|
||||||
|
|
||||||
An authorization policy can be composed by one or more rules. If more
|
|
||||||
rules are specified then the evaluation policy succeeds if any of the
|
|
||||||
rules evaluates successfully; if an API operation matches multiple
|
|
||||||
policies, then all the policies must evaluate successfully. Also,
|
|
||||||
authorization rules are recursive. Once a rule is matched, the rule(s)
|
|
||||||
can be resolved to another rule, until a terminal rule is reached.
|
|
||||||
|
|
||||||
The Networking policy engine currently defines the following kinds of
|
|
||||||
terminal rules:
|
|
||||||
|
|
||||||
- **Role-based rules** evaluate successfully if the user who submits
|
|
||||||
the request has the specified role. For instance ``"role:admin"`` is
|
|
||||||
successful if the user who submits the request is an administrator.
|
|
||||||
|
|
||||||
- **Field-based rules** evaluate successfully if a field of the
|
|
||||||
resource specified in the current request matches a specific value.
|
|
||||||
For instance ``"field:networks:shared=True"`` is successful if the
|
|
||||||
``shared`` attribute of the ``network`` resource is set to true.
|
|
||||||
|
|
||||||
- **Generic rules** compare an attribute in the resource with an
|
|
||||||
attribute extracted from the user's security credentials and
|
|
||||||
evaluates successfully if the comparison is successful. For instance
|
|
||||||
``"tenant_id:%(tenant_id)s"`` is successful if the project identifier
|
|
||||||
in the resource is equal to the project identifier of the user
|
|
||||||
submitting the request.
|
|
||||||
|
|
||||||
This extract is from the default ``policy.yaml`` file:
|
|
||||||
|
|
||||||
- A rule that evaluates successfully if the current user is an
|
|
||||||
administrator or the owner of the resource specified in the request
|
|
||||||
(project identifier is equal).
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
"admin_or_owner": "role:admin or tenant_id:%(tenant_id)s"
|
|
||||||
"admin_or_network_owner": "role:admin or tenant_id:%(network_tenant_id)s"
|
|
||||||
"admin_only": "role:admin"
|
|
||||||
"regular_user": ""
|
|
||||||
"shared": "field:networks:shared=True"
|
|
||||||
|
|
||||||
- The default policy that is always evaluated if an API operation does
|
|
||||||
not match any of the policies in ``policy.yaml``.
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
"default": "rule:admin_or_owner"
|
|
||||||
"create_subnet": "rule:admin_or_network_owner"
|
|
||||||
"get_subnet": "rule:admin_or_owner or rule:shared"
|
|
||||||
"update_subnet": "rule:admin_or_network_owner"
|
|
||||||
"delete_subnet": "rule:admin_or_network_owner"
|
|
||||||
"create_network": ""
|
|
||||||
|
|
||||||
- This policy evaluates successfully if either *admin_or_owner*, or
|
|
||||||
*shared* evaluates successfully.
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
"get_network": "rule:admin_or_owner or rule:shared"
|
|
||||||
"create_network:shared": "rule:admin_only"
|
|
||||||
|
|
||||||
- This policy restricts the ability to manipulate the *shared*
|
|
||||||
attribute for a network to administrators only.
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
"update_network": "rule:admin_or_owner"
|
|
||||||
"delete_network": "rule:admin_or_owner"
|
|
||||||
"create_port": ""
|
|
||||||
"create_port:mac_address": "rule:admin_or_network_owner"
|
|
||||||
"create_port:fixed_ips": "rule:admin_or_network_owner"
|
|
||||||
|
|
||||||
- This policy restricts the ability to manipulate the *mac_address*
|
|
||||||
attribute for a port only to administrators and the owner of the
|
|
||||||
network where the port is attached.
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
"get_port": "rule:admin_or_owner"
|
|
||||||
"update_port": "rule:admin_or_owner"
|
|
||||||
"delete_port": "rule:admin_or_owner"
|
|
||||||
|
|
||||||
In some cases, some operations are restricted to administrators only.
|
|
||||||
This example shows you how to modify a policy file to permit project to
|
|
||||||
define networks, see their resources, and permit administrative users to
|
|
||||||
perform all other operations:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
"admin_or_owner": "role:admin or tenant_id:%(tenant_id)s"
|
|
||||||
"admin_only": "role:admin"
|
|
||||||
"regular_user": ""
|
|
||||||
"default": "rule:admin_only"
|
|
||||||
"create_subnet": "rule:admin_only"
|
|
||||||
"get_subnet": "rule:admin_or_owner"
|
|
||||||
"update_subnet": "rule:admin_only"
|
|
||||||
"delete_subnet": "rule:admin_only"
|
|
||||||
"create_network": ""
|
|
||||||
"get_network": "rule:admin_or_owner"
|
|
||||||
"create_network:shared": "rule:admin_only"
|
|
||||||
"update_network": "rule:admin_or_owner"
|
|
||||||
"delete_network": "rule:admin_or_owner"
|
|
||||||
"create_port": "rule:admin_only"
|
|
||||||
"get_port": "rule:admin_or_owner"
|
|
||||||
"update_port": "rule:admin_only"
|
|
||||||
"delete_port": "rule:admin_only"
|
|
||||||
@@ -1,441 +0,0 @@
|
|||||||
========================
|
|
||||||
Configure neutron agents
|
|
||||||
========================
|
|
||||||
|
|
||||||
Plug-ins typically have requirements for particular software that must
|
|
||||||
be run on each node that handles data packets. This includes any node
|
|
||||||
that runs nova-compute and nodes that run dedicated OpenStack Networking
|
|
||||||
service agents such as ``neutron-dhcp-agent``, ``neutron-l3-agent`` or
|
|
||||||
``neutron-metering-agent``.
|
|
||||||
|
|
||||||
A data-forwarding node typically has a network interface with an IP
|
|
||||||
address on the management network and another interface on the data
|
|
||||||
network.
|
|
||||||
|
|
||||||
This section shows you how to install and configure a subset of the
|
|
||||||
available plug-ins, which might include the installation of switching
|
|
||||||
software (for example, ``Open vSwitch``) and as agents used to communicate
|
|
||||||
with the ``neutron-server`` process running elsewhere in the data center.
|
|
||||||
|
|
||||||
Configure data-forwarding nodes
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Node set up: NSX plug-in
|
|
||||||
------------------------
|
|
||||||
|
|
||||||
If you use the NSX plug-in, you must also install Open vSwitch on each
|
|
||||||
data-forwarding node. However, you do not need to install an additional
|
|
||||||
agent on each node.
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
It is critical that you run an Open vSwitch version that is
|
|
||||||
compatible with the current version of the NSX Controller software.
|
|
||||||
Do not use the Open vSwitch version that is installed by default on
|
|
||||||
Ubuntu. Instead, use the Open vSwitch version that is provided on
|
|
||||||
the VMware support portal for your NSX Controller version.
|
|
||||||
|
|
||||||
**To set up each node for the NSX plug-in**
|
|
||||||
|
|
||||||
#. Ensure that each data-forwarding node has an IP address on the
|
|
||||||
management network, and an IP address on the data network that is used
|
|
||||||
for tunneling data traffic. For full details on configuring your
|
|
||||||
forwarding node, see the `NSX Administration Guide
|
|
||||||
<https://www.vmware.com/support/pubs/>`__.
|
|
||||||
|
|
||||||
#. Use the NSX Administrator Guide to add the node as a Hypervisor
|
|
||||||
by using the NSX Manager GUI. Even if your forwarding node has no
|
|
||||||
VMs and is only used for services agents like ``neutron-dhcp-agent``
|
|
||||||
, it should still be added to NSX as a
|
|
||||||
Hypervisor.
|
|
||||||
|
|
||||||
#. After following the NSX Administrator Guide, use the page for this
|
|
||||||
Hypervisor in the NSX Manager GUI to confirm that the node is properly
|
|
||||||
connected to the NSX Controller Cluster and that the NSX Controller
|
|
||||||
Cluster can see the ``br-int`` integration bridge.
|
|
||||||
|
|
||||||
Configure DHCP agent
|
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The DHCP service agent is compatible with all existing plug-ins and is
|
|
||||||
required for all deployments where VMs should automatically receive IP
|
|
||||||
addresses through DHCP.
|
|
||||||
|
|
||||||
**To install and configure the DHCP agent**
|
|
||||||
|
|
||||||
#. You must configure the host running the neutron-dhcp-agent as a data
|
|
||||||
forwarding node according to the requirements for your plug-in.
|
|
||||||
|
|
||||||
#. Install the DHCP agent:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# apt-get install neutron-dhcp-agent
|
|
||||||
|
|
||||||
#. Update any options in the ``/etc/neutron/dhcp_agent.ini`` file
|
|
||||||
that depend on the plug-in in use. See the sub-sections.
|
|
||||||
|
|
||||||
.. important::
|
|
||||||
|
|
||||||
If you reboot a node that runs the DHCP agent, you must run the
|
|
||||||
:command:`neutron-ovs-cleanup` command before the ``neutron-dhcp-agent``
|
|
||||||
service starts.
|
|
||||||
|
|
||||||
On Red Hat, SUSE, and Ubuntu based systems, the
|
|
||||||
``neutron-ovs-cleanup`` service runs the :command:`neutron-ovs-cleanup`
|
|
||||||
command automatically. However, on Debian-based systems, you
|
|
||||||
must manually run this command or write your own system script
|
|
||||||
that runs on boot before the ``neutron-dhcp-agent`` service starts.
|
|
||||||
|
|
||||||
Networking dhcp-agent can use
|
|
||||||
`dnsmasq <http://www.thekelleys.org.uk/dnsmasq/doc.html>`__ driver which
|
|
||||||
supports stateful and stateless DHCPv6 for subnets created with
|
|
||||||
``--ipv6_address_mode`` set to ``dhcpv6-stateful`` or
|
|
||||||
``dhcpv6-stateless``.
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack subnet create --ip-version 6 --ipv6-ra-mode dhcpv6-stateful \
|
|
||||||
--ipv6-address-mode dhcpv6-stateful --network NETWORK --subnet-range \
|
|
||||||
CIDR SUBNET_NAME
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack subnet create --ip-version 6 --ipv6-ra-mode dhcpv6-stateless \
|
|
||||||
--ipv6-address-mode dhcpv6-stateless --network NETWORK --subnet-range \
|
|
||||||
CIDR SUBNET_NAME
|
|
||||||
|
|
||||||
If no dnsmasq process for subnet's network is launched, Networking will
|
|
||||||
launch a new one on subnet's dhcp port in ``qdhcp-XXX`` namespace. If
|
|
||||||
previous dnsmasq process is already launched, restart dnsmasq with a new
|
|
||||||
configuration.
|
|
||||||
|
|
||||||
Networking will update dnsmasq process and restart it when subnet gets
|
|
||||||
updated.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
For dhcp-agent to operate in IPv6 mode use at least dnsmasq v2.63.
|
|
||||||
|
|
||||||
After a certain, configured timeframe, networks uncouple from DHCP
|
|
||||||
agents when the agents are no longer in use. You can configure the DHCP
|
|
||||||
agent to automatically detach from a network when the agent is out of
|
|
||||||
service, or no longer needed.
|
|
||||||
|
|
||||||
This feature applies to all plug-ins that support DHCP scaling. For more
|
|
||||||
information, see the `DHCP agent configuration
|
|
||||||
options <https://docs.openstack.org/ocata/config-reference/networking/networking_options_reference.html#dhcp-agent>`__
|
|
||||||
listed in the OpenStack Configuration Reference.
|
|
||||||
|
|
||||||
DHCP agent setup: OVS plug-in
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
These DHCP agent options are required in the
|
|
||||||
``/etc/neutron/dhcp_agent.ini`` file for the OVS plug-in:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
enable_isolated_metadata = True
|
|
||||||
interface_driver = openvswitch
|
|
||||||
|
|
||||||
DHCP agent setup: NSX plug-in
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
These DHCP agent options are required in the
|
|
||||||
``/etc/neutron/dhcp_agent.ini`` file for the NSX plug-in:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
enable_metadata_network = True
|
|
||||||
enable_isolated_metadata = True
|
|
||||||
interface_driver = openvswitch
|
|
||||||
|
|
||||||
DHCP agent setup: Linux-bridge plug-in
|
|
||||||
--------------------------------------
|
|
||||||
|
|
||||||
These DHCP agent options are required in the
|
|
||||||
``/etc/neutron/dhcp_agent.ini`` file for the Linux-bridge plug-in:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
enabled_isolated_metadata = True
|
|
||||||
interface_driver = linuxbridge
|
|
||||||
|
|
||||||
Configure L3 agent
|
|
||||||
~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The OpenStack Networking service has a widely used API extension to
|
|
||||||
allow administrators and projects to create routers to interconnect L2
|
|
||||||
networks, and floating IPs to make ports on private networks publicly
|
|
||||||
accessible.
|
|
||||||
|
|
||||||
Many plug-ins rely on the L3 service agent to implement the L3
|
|
||||||
functionality. However, the following plug-ins already have built-in L3
|
|
||||||
capabilities:
|
|
||||||
|
|
||||||
- Big Switch/Floodlight plug-in, which supports both the open source
|
|
||||||
`Floodlight <https://github.com/floodlight/floodlight>`__
|
|
||||||
controller and the proprietary Big Switch controller.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Only the proprietary BigSwitch controller implements L3
|
|
||||||
functionality. When using Floodlight as your OpenFlow controller,
|
|
||||||
L3 functionality is not available.
|
|
||||||
|
|
||||||
- IBM SDN-VE plug-in
|
|
||||||
|
|
||||||
- MidoNet plug-in
|
|
||||||
|
|
||||||
- NSX plug-in
|
|
||||||
|
|
||||||
- PLUMgrid plug-in
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
Do not configure or use ``neutron-l3-agent`` if you use one of these
|
|
||||||
plug-ins.
|
|
||||||
|
|
||||||
**To install the L3 agent for all other plug-ins**
|
|
||||||
|
|
||||||
#. Install the ``neutron-l3-agent`` binary on the network node:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# apt-get install neutron-l3-agent
|
|
||||||
|
|
||||||
#. To uplink the node that runs ``neutron-l3-agent`` to the external network,
|
|
||||||
create a bridge named ``br-ex`` and attach the NIC for the external
|
|
||||||
network to this bridge.
|
|
||||||
|
|
||||||
For example, with Open vSwitch and NIC eth1 connected to the external
|
|
||||||
network, run:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# ovs-vsctl add-br br-ex
|
|
||||||
# ovs-vsctl add-port br-ex eth1
|
|
||||||
|
|
||||||
When the ``br-ex`` port is added to the ``eth1`` interface, external
|
|
||||||
communication is interrupted. To avoid this, edit the
|
|
||||||
``/etc/network/interfaces`` file to contain the following information:
|
|
||||||
|
|
||||||
.. code-block:: shell
|
|
||||||
|
|
||||||
## External bridge
|
|
||||||
auto br-ex
|
|
||||||
iface br-ex inet static
|
|
||||||
address 192.27.117.101
|
|
||||||
netmask 255.255.240.0
|
|
||||||
gateway 192.27.127.254
|
|
||||||
dns-nameservers 8.8.8.8
|
|
||||||
|
|
||||||
## External network interface
|
|
||||||
auto eth1
|
|
||||||
iface eth1 inet manual
|
|
||||||
up ifconfig $IFACE 0.0.0.0 up
|
|
||||||
up ip link set $IFACE promisc on
|
|
||||||
down ip link set $IFACE promisc off
|
|
||||||
down ifconfig $IFACE down
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The external bridge configuration address is the external IP address.
|
|
||||||
This address and gateway should be configured in
|
|
||||||
``/etc/network/interfaces``.
|
|
||||||
|
|
||||||
After editing the configuration, restart ``br-ex``:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# ifdown br-ex && ifup br-ex
|
|
||||||
|
|
||||||
Do not manually configure an IP address on the NIC connected to the
|
|
||||||
external network for the node running ``neutron-l3-agent``. Rather, you
|
|
||||||
must have a range of IP addresses from the external network that can be
|
|
||||||
used by OpenStack Networking for routers that uplink to the external
|
|
||||||
network. This range must be large enough to have an IP address for each
|
|
||||||
router in the deployment, as well as each floating IP.
|
|
||||||
|
|
||||||
#. The ``neutron-l3-agent`` uses the Linux IP stack and iptables to perform L3
|
|
||||||
forwarding and NAT. In order to support multiple routers with
|
|
||||||
potentially overlapping IP addresses, ``neutron-l3-agent`` defaults to
|
|
||||||
using Linux network namespaces to provide isolated forwarding contexts.
|
|
||||||
As a result, the IP addresses of routers are not visible simply by running
|
|
||||||
the :command:`ip addr list` or :command:`ifconfig` command on the node.
|
|
||||||
Similarly, you cannot directly :command:`ping` fixed IPs.
|
|
||||||
|
|
||||||
To do either of these things, you must run the command within a
|
|
||||||
particular network namespace for the router. The namespace has the name
|
|
||||||
``qrouter-ROUTER_UUID``. These example commands run in the router
|
|
||||||
namespace with UUID 47af3868-0fa8-4447-85f6-1304de32153b:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# ip netns exec qrouter-47af3868-0fa8-4447-85f6-1304de32153b ip addr list
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# ip netns exec qrouter-47af3868-0fa8-4447-85f6-1304de32153b ping FIXED_IP
|
|
||||||
|
|
||||||
.. important::
|
|
||||||
|
|
||||||
If you reboot a node that runs the L3 agent, you must run the
|
|
||||||
:command:`neutron-ovs-cleanup` command before the ``neutron-l3-agent``
|
|
||||||
service starts.
|
|
||||||
|
|
||||||
On Red Hat, SUSE and Ubuntu based systems, the neutron-ovs-cleanup
|
|
||||||
service runs the :command:`neutron-ovs-cleanup` command
|
|
||||||
automatically. However, on Debian-based systems, you must manually
|
|
||||||
run this command or write your own system script that runs on boot
|
|
||||||
before the neutron-l3-agent service starts.
|
|
||||||
|
|
||||||
**How routers are assigned to L3 agents**
|
|
||||||
By default, a router is assigned to the L3 agent with the least number
|
|
||||||
of routers (LeastRoutersScheduler). This can be changed by altering the
|
|
||||||
``router_scheduler_driver`` setting in the configuration file.
|
|
||||||
|
|
||||||
Configure metering agent
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The Neutron Metering agent resides beside neutron-l3-agent.
|
|
||||||
|
|
||||||
**To install the metering agent and configure the node**
|
|
||||||
|
|
||||||
#. Install the agent by running:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# apt-get install neutron-metering-agent
|
|
||||||
|
|
||||||
#. If you use one of the following plug-ins, you need to configure the
|
|
||||||
metering agent with these lines as well:
|
|
||||||
|
|
||||||
- An OVS-based plug-in such as OVS, NSX, NEC, BigSwitch/Floodlight:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
interface_driver = openvswitch
|
|
||||||
|
|
||||||
- A plug-in that uses LinuxBridge:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
interface_driver = linuxbridge
|
|
||||||
|
|
||||||
#. To use the reference implementation, you must set:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
driver = iptables
|
|
||||||
|
|
||||||
#. Set the ``service_plugins`` option in the ``/etc/neutron/neutron.conf``
|
|
||||||
file on the host that runs ``neutron-server``:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
service_plugins = metering
|
|
||||||
|
|
||||||
If this option is already defined, add ``metering`` to the list, using a
|
|
||||||
comma as separator. For example:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
service_plugins = router,metering
|
|
||||||
|
|
||||||
Configure Hyper-V L2 agent
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Before you install the OpenStack Networking Hyper-V L2 agent on a
|
|
||||||
Hyper-V compute node, ensure the compute node has been configured
|
|
||||||
correctly using these
|
|
||||||
`instructions <https://docs.openstack.org/ocata/config-reference/compute/hypervisor-hyper-v.html>`__.
|
|
||||||
|
|
||||||
**To install the OpenStack Networking Hyper-V agent and configure the node**
|
|
||||||
|
|
||||||
#. Download the OpenStack Networking code from the repository:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
> cd C:\OpenStack\
|
|
||||||
> git clone https://opendev.org/openstack/neutron
|
|
||||||
|
|
||||||
#. Install the OpenStack Networking Hyper-V Agent:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
> cd C:\OpenStack\neutron\
|
|
||||||
> python setup.py install
|
|
||||||
|
|
||||||
#. Copy the ``policy.yaml`` file:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
> xcopy C:\OpenStack\neutron\etc\policy.yaml C:\etc\
|
|
||||||
|
|
||||||
#. Create the ``C:\etc\neutron-hyperv-agent.conf`` file and add the proper
|
|
||||||
configuration options and the `Hyper-V related
|
|
||||||
options <https://docs.openstack.org/ocata/config-reference/networking/networking_options_reference.html#cloudbase-hyper-v-agent-configuration-options>`__. Here is a sample config file:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
control_exchange = neutron
|
|
||||||
policy_file = C:\etc\policy.yaml
|
|
||||||
rpc_backend = neutron.openstack.common.rpc.impl_kombu
|
|
||||||
rabbit_host = IP_ADDRESS
|
|
||||||
rabbit_port = 5672
|
|
||||||
rabbit_userid = guest
|
|
||||||
rabbit_password = <password>
|
|
||||||
logdir = C:\OpenStack\Log
|
|
||||||
logfile = neutron-hyperv-agent.log
|
|
||||||
|
|
||||||
[AGENT]
|
|
||||||
polling_interval = 2
|
|
||||||
physical_network_vswitch_mappings = *:YOUR_BRIDGE_NAME
|
|
||||||
enable_metrics_collection = true
|
|
||||||
|
|
||||||
[SECURITYGROUP]
|
|
||||||
firewall_driver = hyperv.neutron.security_groups_driver.HyperVSecurityGroupsDriver
|
|
||||||
enable_security_group = true
|
|
||||||
|
|
||||||
#. Start the OpenStack Networking Hyper-V agent:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
> C:\Python27\Scripts\neutron-hyperv-agent.exe --config-file
|
|
||||||
C:\etc\neutron-hyperv-agent.conf
|
|
||||||
|
|
||||||
Basic operations on agents
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This table shows examples of Networking commands that enable you to
|
|
||||||
complete basic operations on agents.
|
|
||||||
|
|
||||||
.. list-table::
|
|
||||||
:widths: 50 50
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Operation
|
|
||||||
- Command
|
|
||||||
* - List all available agents.
|
|
||||||
- ``$ openstack network agent list``
|
|
||||||
* - Show information of a given agent.
|
|
||||||
- ``$ openstack network agent show AGENT_ID``
|
|
||||||
* - Update the admin status and description for a specified agent. The
|
|
||||||
command can be used to enable and disable agents by using
|
|
||||||
``--admin-state-up`` parameter set to ``False`` or ``True``.
|
|
||||||
- ``$ neutron agent-update --admin-state-up False AGENT_ID``
|
|
||||||
* - Delete a given agent. Consider disabling the agent before deletion.
|
|
||||||
- ``$ openstack network agent delete AGENT_ID``
|
|
||||||
|
|
||||||
**Basic operations on Networking agents**
|
|
||||||
|
|
||||||
See the `OpenStack Command-Line Interface
|
|
||||||
Reference <https://docs.openstack.org/cli-reference/neutron.html>`__
|
|
||||||
for more information on Networking commands.
|
|
||||||
@@ -1,306 +0,0 @@
|
|||||||
=========================================
|
|
||||||
Configure Identity service for Networking
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
**To configure the Identity service for use with Networking**
|
|
||||||
|
|
||||||
#. Create the ``get_id()`` function
|
|
||||||
|
|
||||||
The ``get_id()`` function stores the ID of created objects, and removes
|
|
||||||
the need to copy and paste object IDs in later steps:
|
|
||||||
|
|
||||||
a. Add the following function to your ``.bashrc`` file:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
function get_id () {
|
|
||||||
echo `"$@" | awk '/ id / { print $4 }'`
|
|
||||||
}
|
|
||||||
|
|
||||||
b. Source the ``.bashrc`` file:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ source .bashrc
|
|
||||||
|
|
||||||
#. Create the Networking service entry
|
|
||||||
|
|
||||||
Networking must be available in the Compute service catalog. Create the
|
|
||||||
service:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ NEUTRON_SERVICE_ID=$(get_id openstack service create network \
|
|
||||||
--name neutron --description 'OpenStack Networking Service')
|
|
||||||
|
|
||||||
#. Create the Networking service endpoint entry
|
|
||||||
|
|
||||||
The way that you create a Networking endpoint entry depends on whether
|
|
||||||
you are using the SQL or the template catalog driver:
|
|
||||||
|
|
||||||
- If you are using the ``SQL driver``, run the following command with the
|
|
||||||
specified region (``$REGION``), IP address of the Networking server
|
|
||||||
(``$IP``), and service ID (``$NEUTRON_SERVICE_ID``, obtained in the
|
|
||||||
previous step).
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack endpoint create $NEUTRON_SERVICE_ID --region $REGION \
|
|
||||||
--publicurl 'http://$IP:9696/' --adminurl 'http://$IP:9696/' \
|
|
||||||
--internalurl 'http://$IP:9696/'
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack endpoint create $NEUTRON_SERVICE_ID --region myregion \
|
|
||||||
--publicurl "http://10.211.55.17:9696/" \
|
|
||||||
--adminurl "http://10.211.55.17:9696/" \
|
|
||||||
--internalurl "http://10.211.55.17:9696/"
|
|
||||||
|
|
||||||
- If you are using the ``template driver``, specify the following
|
|
||||||
parameters in your Compute catalog template file
|
|
||||||
(``default_catalog.templates``), along with the region (``$REGION``)
|
|
||||||
and IP address of the Networking server (``$IP``).
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
catalog.$REGION.network.publicURL = http://$IP:9696
|
|
||||||
catalog.$REGION.network.adminURL = http://$IP:9696
|
|
||||||
catalog.$REGION.network.internalURL = http://$IP:9696
|
|
||||||
catalog.$REGION.network.name = Network Service
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
catalog.$Region.network.publicURL = http://10.211.55.17:9696
|
|
||||||
catalog.$Region.network.adminURL = http://10.211.55.17:9696
|
|
||||||
catalog.$Region.network.internalURL = http://10.211.55.17:9696
|
|
||||||
catalog.$Region.network.name = Network Service
|
|
||||||
|
|
||||||
#. Create the Networking service user
|
|
||||||
|
|
||||||
You must provide admin user credentials that Compute and some internal
|
|
||||||
Networking components can use to access the Networking API. Create a
|
|
||||||
special ``service`` project and a ``neutron`` user within this project,
|
|
||||||
and assign an ``admin`` role to this role.
|
|
||||||
|
|
||||||
a. Create the ``admin`` role:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ ADMIN_ROLE=$(get_id openstack role create admin)
|
|
||||||
|
|
||||||
b. Create the ``neutron`` user:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ NEUTRON_USER=$(get_id openstack user create neutron \
|
|
||||||
--password "$NEUTRON_PASSWORD" --email demo@example.com \
|
|
||||||
--project service)
|
|
||||||
|
|
||||||
c. Create the ``service`` project:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ SERVICE_TENANT=$(get_id openstack project create service \
|
|
||||||
--description "Services project" --domain default)
|
|
||||||
|
|
||||||
d. Establish the relationship among the project, user, and role:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack role add $ADMIN_ROLE --user $NEUTRON_USER \
|
|
||||||
--project $SERVICE_TENANT
|
|
||||||
|
|
||||||
For information about how to create service entries and users, see the `Ocata Installation
|
|
||||||
Tutorials and Guides <https://docs.openstack.org/project-install-guide/ocata/>`_
|
|
||||||
for your distribution.
|
|
||||||
|
|
||||||
Compute
|
|
||||||
~~~~~~~
|
|
||||||
|
|
||||||
If you use Networking, do not run the Compute ``nova-network`` service (like
|
|
||||||
you do in traditional Compute deployments). Instead, Compute delegates
|
|
||||||
most network-related decisions to Networking.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Uninstall ``nova-network`` and reboot any physical nodes that have been
|
|
||||||
running ``nova-network`` before using them to run Networking.
|
|
||||||
Inadvertently running the ``nova-network`` process while using
|
|
||||||
Networking can cause problems, as can stale iptables rules pushed
|
|
||||||
down by previously running ``nova-network``.
|
|
||||||
|
|
||||||
Compute proxies project-facing API calls to manage security groups and
|
|
||||||
floating IPs to Networking APIs. However, operator-facing tools such
|
|
||||||
as ``nova-manage``, are not proxied and should not be used.
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
When you configure networking, you must use this guide. Do not rely
|
|
||||||
on Compute networking documentation or past experience with Compute.
|
|
||||||
If a :command:`nova` command or configuration option related to networking
|
|
||||||
is not mentioned in this guide, the command is probably not
|
|
||||||
supported for use with Networking. In particular, you cannot use CLI
|
|
||||||
tools like ``nova-manage`` and ``nova`` to manage networks or IP
|
|
||||||
addressing, including both fixed and floating IPs, with Networking.
|
|
||||||
|
|
||||||
To ensure that Compute works properly with Networking (rather than the
|
|
||||||
legacy ``nova-network`` mechanism), you must adjust settings in the
|
|
||||||
``nova.conf`` configuration file.
|
|
||||||
|
|
||||||
Networking API and credential configuration
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Each time you provision or de-provision a VM in Compute, ``nova-\*``
|
|
||||||
services communicate with Networking using the standard API. For this to
|
|
||||||
happen, you must configure the following items in the ``nova.conf`` file
|
|
||||||
(used by each ``nova-compute`` and ``nova-api`` instance).
|
|
||||||
|
|
||||||
.. list-table:: **nova.conf API and credential settings prior to Mitaka**
|
|
||||||
:widths: 20 50
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Attribute name
|
|
||||||
- Required
|
|
||||||
* - ``[DEFAULT] use_neutron``
|
|
||||||
- Modify from the default to ``True`` to
|
|
||||||
indicate that Networking should be used rather than the traditional
|
|
||||||
nova-network networking model.
|
|
||||||
* - ``[neutron] url``
|
|
||||||
- Update to the host name/IP and port of the neutron-server instance
|
|
||||||
for this deployment.
|
|
||||||
* - ``[neutron] auth_strategy``
|
|
||||||
- Keep the default ``keystone`` value for all production deployments.
|
|
||||||
* - ``[neutron] admin_project_name``
|
|
||||||
- Update to the name of the service tenant created in the above section on
|
|
||||||
Identity configuration.
|
|
||||||
* - ``[neutron] admin_username``
|
|
||||||
- Update to the name of the user created in the above section on Identity
|
|
||||||
configuration.
|
|
||||||
* - ``[neutron] admin_password``
|
|
||||||
- Update to the password of the user created in the above section on
|
|
||||||
Identity configuration.
|
|
||||||
* - ``[neutron] admin_auth_url``
|
|
||||||
- Update to the Identity server IP and port. This is the Identity
|
|
||||||
(keystone) admin API server IP and port value, and not the Identity
|
|
||||||
service API IP and port.
|
|
||||||
|
|
||||||
.. list-table:: **nova.conf API and credential settings in Newton**
|
|
||||||
:widths: 20 50
|
|
||||||
:header-rows: 1
|
|
||||||
|
|
||||||
* - Attribute name
|
|
||||||
- Required
|
|
||||||
* - ``[DEFAULT] use_neutron``
|
|
||||||
- Modify from the default to ``True`` to
|
|
||||||
indicate that Networking should be used rather than the traditional
|
|
||||||
nova-network networking model.
|
|
||||||
* - ``[neutron] url``
|
|
||||||
- Update to the host name/IP and port of the neutron-server instance
|
|
||||||
for this deployment.
|
|
||||||
* - ``[neutron] auth_strategy``
|
|
||||||
- Keep the default ``keystone`` value for all production deployments.
|
|
||||||
* - ``[neutron] project_name``
|
|
||||||
- Update to the name of the service tenant created in the above section on
|
|
||||||
Identity configuration.
|
|
||||||
* - ``[neutron] username``
|
|
||||||
- Update to the name of the user created in the above section on Identity
|
|
||||||
configuration.
|
|
||||||
* - ``[neutron] password``
|
|
||||||
- Update to the password of the user created in the above section on
|
|
||||||
Identity configuration.
|
|
||||||
* - ``[neutron] auth_url``
|
|
||||||
- Update to the Identity server IP and port. This is the Identity
|
|
||||||
(keystone) admin API server IP and port value, and not the Identity
|
|
||||||
service API IP and port.
|
|
||||||
|
|
||||||
Configure security groups
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The Networking service provides security group functionality using a
|
|
||||||
mechanism that is more flexible and powerful than the security group
|
|
||||||
capabilities built into Compute. Therefore, if you use Networking, you
|
|
||||||
should always disable built-in security groups and proxy all security
|
|
||||||
group calls to the Networking API. If you do not, security policies
|
|
||||||
will conflict by being simultaneously applied by both services.
|
|
||||||
|
|
||||||
To proxy security groups to Networking, use the following configuration
|
|
||||||
values in the ``nova.conf`` file:
|
|
||||||
|
|
||||||
**nova.conf security group settings**
|
|
||||||
|
|
||||||
+-----------------------+-----------------------------------------------------+
|
|
||||||
| Item | Configuration |
|
|
||||||
+=======================+=====================================================+
|
|
||||||
| ``firewall_driver`` | Update to ``nova.virt.firewall.NoopFirewallDriver``,|
|
|
||||||
| | so that nova-compute does not perform |
|
|
||||||
| | iptables-based filtering itself. |
|
|
||||||
+-----------------------+-----------------------------------------------------+
|
|
||||||
|
|
||||||
Configure metadata
|
|
||||||
~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The Compute service allows VMs to query metadata associated with a VM by
|
|
||||||
making a web request to a special 169.254.169.254 address. Networking
|
|
||||||
supports proxying those requests to nova-api, even when the requests are
|
|
||||||
made from isolated networks, or from multiple networks that use
|
|
||||||
overlapping IP addresses.
|
|
||||||
|
|
||||||
To enable proxying the requests, you must update the following fields in
|
|
||||||
``[neutron]`` section in the ``nova.conf``.
|
|
||||||
|
|
||||||
**nova.conf metadata settings**
|
|
||||||
|
|
||||||
+---------------------------------+------------------------------------------+
|
|
||||||
| Item | Configuration |
|
|
||||||
+=================================+==========================================+
|
|
||||||
| ``service_metadata_proxy`` | Update to ``true``, otherwise nova-api |
|
|
||||||
| | will not properly respond to requests |
|
|
||||||
| | from the neutron-metadata-agent. |
|
|
||||||
+---------------------------------+------------------------------------------+
|
|
||||||
| ``metadata_proxy_shared_secret``| Update to a string "password" value. |
|
|
||||||
| | You must also configure the same value in|
|
|
||||||
| | the ``metadata_agent.ini`` file, to |
|
|
||||||
| | authenticate requests made for metadata. |
|
|
||||||
| | |
|
|
||||||
| | The default value of an empty string in |
|
|
||||||
| | both files will allow metadata to |
|
|
||||||
| | function, but will not be secure if any |
|
|
||||||
| | non-trusted entities have access to the |
|
|
||||||
| | metadata APIs exposed by nova-api. |
|
|
||||||
+---------------------------------+------------------------------------------+
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
As a precaution, even when using ``metadata_proxy_shared_secret``,
|
|
||||||
we recommend that you do not expose metadata using the same
|
|
||||||
nova-api instances that are used for projects. Instead, you should
|
|
||||||
run a dedicated set of nova-api instances for metadata that are
|
|
||||||
available only on your management network. Whether a given nova-api
|
|
||||||
instance exposes metadata APIs is determined by the value of
|
|
||||||
``enabled_apis`` in its ``nova.conf``.
|
|
||||||
|
|
||||||
Example nova.conf (for nova-compute and nova-api)
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Example values for the above settings, assuming a cloud controller node
|
|
||||||
running Compute and Networking with an IP address of 192.168.1.2:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
use_neutron = True
|
|
||||||
firewall_driver=nova.virt.firewall.NoopFirewallDriver
|
|
||||||
|
|
||||||
[neutron]
|
|
||||||
url=http://192.168.1.2:9696
|
|
||||||
auth_strategy=keystone
|
|
||||||
admin_tenant_name=service
|
|
||||||
admin_username=neutron
|
|
||||||
admin_password=password
|
|
||||||
admin_auth_url=http://192.168.1.2:5000/v2.0
|
|
||||||
service_metadata_proxy=true
|
|
||||||
metadata_proxy_shared_secret=foo
|
|
||||||
@@ -1,245 +0,0 @@
|
|||||||
======================
|
|
||||||
Plug-in configurations
|
|
||||||
======================
|
|
||||||
|
|
||||||
For configurations options, see `Networking configuration
|
|
||||||
options <https://docs.openstack.org/ocata/config-reference/networking/networking_options_reference.html>`__
|
|
||||||
in Configuration Reference. These sections explain how to configure
|
|
||||||
specific plug-ins.
|
|
||||||
|
|
||||||
Configure Big Switch (Floodlight REST Proxy) plug-in
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
#. Edit the ``/etc/neutron/neutron.conf`` file and add this line:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
core_plugin = bigswitch
|
|
||||||
|
|
||||||
#. In the ``/etc/neutron/neutron.conf`` file, set the ``service_plugins``
|
|
||||||
option:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
service_plugins = neutron.plugins.bigswitch.l3_router_plugin.L3RestProxy
|
|
||||||
|
|
||||||
#. Edit the ``/etc/neutron/plugins/bigswitch/restproxy.ini`` file for the
|
|
||||||
plug-in and specify a comma-separated list of controller\_ip:port pairs:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
server = CONTROLLER_IP:PORT
|
|
||||||
|
|
||||||
For database configuration, see `Install Networking
|
|
||||||
Services <https://docs.openstack.org/ocata/install-guide-ubuntu/neutron-controller-install.html>`__
|
|
||||||
in the Installation Tutorials and Guides. (The link defaults to the Ubuntu
|
|
||||||
version.)
|
|
||||||
|
|
||||||
#. Restart the ``neutron-server`` to apply the settings:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# service neutron-server restart
|
|
||||||
|
|
||||||
Configure Brocade plug-in
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
#. Install the Brocade-modified Python netconf client (ncclient) library,
|
|
||||||
which is available at https://github.com/brocade/ncclient:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ git clone https://github.com/brocade/ncclient
|
|
||||||
|
|
||||||
#. As root, run this command:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# cd ncclient;python setup.py install
|
|
||||||
|
|
||||||
#. Edit the ``/etc/neutron/neutron.conf`` file and set the following
|
|
||||||
option:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
core_plugin = brocade
|
|
||||||
|
|
||||||
#. Edit the ``/etc/neutron/plugins/brocade/brocade.ini`` file for the
|
|
||||||
Brocade plug-in and specify the admin user name, password, and IP
|
|
||||||
address of the Brocade switch:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[SWITCH]
|
|
||||||
username = ADMIN
|
|
||||||
password = PASSWORD
|
|
||||||
address = SWITCH_MGMT_IP_ADDRESS
|
|
||||||
ostype = NOS
|
|
||||||
|
|
||||||
For database configuration, see `Install Networking
|
|
||||||
Services <https://docs.openstack.org/ocata/install-guide-ubuntu/neutron-controller-install.html>`__
|
|
||||||
in any of the Installation Tutorials and Guides in the `OpenStack Documentation
|
|
||||||
index <https://docs.openstack.org>`__. (The link defaults to the Ubuntu
|
|
||||||
version.)
|
|
||||||
|
|
||||||
#. Restart the ``neutron-server`` service to apply the settings:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# service neutron-server restart
|
|
||||||
|
|
||||||
Configure NSX-mh plug-in
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The instructions in this section refer to the VMware NSX-mh platform,
|
|
||||||
formerly known as Nicira NVP.
|
|
||||||
|
|
||||||
#. Install the NSX plug-in:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# apt-get install python-vmware-nsx
|
|
||||||
|
|
||||||
#. Edit the ``/etc/neutron/neutron.conf`` file and set this line:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
core_plugin = vmware
|
|
||||||
|
|
||||||
Example ``neutron.conf`` file for NSX-mh integration:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
core_plugin = vmware
|
|
||||||
rabbit_host = 192.168.203.10
|
|
||||||
|
|
||||||
#. To configure the NSX-mh controller cluster for OpenStack Networking,
|
|
||||||
locate the ``[default]`` section in the
|
|
||||||
``/etc/neutron/plugins/vmware/nsx.ini`` file and add the following
|
|
||||||
entries:
|
|
||||||
|
|
||||||
- To establish and configure the connection with the controller cluster
|
|
||||||
you must set some parameters, including NSX-mh API endpoints, access
|
|
||||||
credentials, and optionally specify settings for HTTP timeouts,
|
|
||||||
redirects and retries in case of connection failures:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
nsx_user = ADMIN_USER_NAME
|
|
||||||
nsx_password = NSX_USER_PASSWORD
|
|
||||||
http_timeout = HTTP_REQUEST_TIMEOUT # (seconds) default 75 seconds
|
|
||||||
retries = HTTP_REQUEST_RETRIES # default 2
|
|
||||||
redirects = HTTP_REQUEST_MAX_REDIRECTS # default 2
|
|
||||||
nsx_controllers = API_ENDPOINT_LIST # comma-separated list
|
|
||||||
|
|
||||||
To ensure correct operations, the ``nsx_user`` user must have
|
|
||||||
administrator credentials on the NSX-mh platform.
|
|
||||||
|
|
||||||
A controller API endpoint consists of the IP address and port for the
|
|
||||||
controller; if you omit the port, port 443 is used. If multiple API
|
|
||||||
endpoints are specified, it is up to the user to ensure that all
|
|
||||||
these endpoints belong to the same controller cluster. The OpenStack
|
|
||||||
Networking VMware NSX-mh plug-in does not perform this check, and
|
|
||||||
results might be unpredictable.
|
|
||||||
|
|
||||||
When you specify multiple API endpoints, the plug-in takes care of
|
|
||||||
load balancing requests on the various API endpoints.
|
|
||||||
|
|
||||||
- The UUID of the NSX-mh transport zone that should be used by default
|
|
||||||
when a project creates a network. You can get this value from the
|
|
||||||
Transport Zones page for the NSX-mh manager:
|
|
||||||
|
|
||||||
Alternatively the transport zone identifier can be retrieved by query
|
|
||||||
the NSX-mh API: ``/ws.v1/transport-zone``
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
default_tz_uuid = TRANSPORT_ZONE_UUID
|
|
||||||
|
|
||||||
- .. code-block:: ini
|
|
||||||
|
|
||||||
default_l3_gw_service_uuid = GATEWAY_SERVICE_UUID
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
Ubuntu packaging currently does not update the neutron init
|
|
||||||
script to point to the NSX-mh configuration file. Instead, you
|
|
||||||
must manually update ``/etc/default/neutron-server`` to add this
|
|
||||||
line:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
NEUTRON_PLUGIN_CONFIG = /etc/neutron/plugins/vmware/nsx.ini
|
|
||||||
|
|
||||||
For database configuration, see `Install Networking
|
|
||||||
Services <https://docs.openstack.org/ocata/install-guide-ubuntu/neutron-controller-install.html>`__
|
|
||||||
in the Installation Tutorials and Guides.
|
|
||||||
|
|
||||||
#. Restart ``neutron-server`` to apply settings:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# service neutron-server restart
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
The neutron NSX-mh plug-in does not implement initial
|
|
||||||
re-synchronization of Neutron resources. Therefore resources that
|
|
||||||
might already exist in the database when Neutron is switched to the
|
|
||||||
NSX-mh plug-in will not be created on the NSX-mh backend upon
|
|
||||||
restart.
|
|
||||||
|
|
||||||
Example ``nsx.ini`` file:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
default_tz_uuid = d3afb164-b263-4aaa-a3e4-48e0e09bb33c
|
|
||||||
default_l3_gw_service_uuid=5c8622cc-240a-40a1-9693-e6a5fca4e3cf
|
|
||||||
nsx_user=admin
|
|
||||||
nsx_password=changeme
|
|
||||||
nsx_controllers=10.127.0.100,10.127.0.200:8888
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
To debug :file:`nsx.ini` configuration issues, run this command from the
|
|
||||||
host that runs neutron-server:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# neutron-check-nsx-config PATH_TO_NSX.INI
|
|
||||||
|
|
||||||
This command tests whether ``neutron-server`` can log into all of the
|
|
||||||
NSX-mh controllers and the SQL server, and whether all UUID values
|
|
||||||
are correct.
|
|
||||||
|
|
||||||
Configure PLUMgrid plug-in
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
#. Edit the ``/etc/neutron/neutron.conf`` file and set this line:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
core_plugin = plumgrid
|
|
||||||
|
|
||||||
#. Edit the [PLUMgridDirector] section in the
|
|
||||||
``/etc/neutron/plugins/plumgrid/plumgrid.ini`` file and specify the IP
|
|
||||||
address, port, admin user name, and password of the PLUMgrid Director:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[PLUMgridDirector]
|
|
||||||
director_server = "PLUMgrid-director-ip-address"
|
|
||||||
director_server_port = "PLUMgrid-director-port"
|
|
||||||
username = "PLUMgrid-director-admin-username"
|
|
||||||
password = "PLUMgrid-director-admin-password"
|
|
||||||
|
|
||||||
For database configuration, see `Install Networking
|
|
||||||
Services <https://docs.openstack.org/ocata/install-guide-ubuntu/neutron-controller-install.html>`__
|
|
||||||
in the Installation Tutorials and Guides.
|
|
||||||
|
|
||||||
#. Restart the ``neutron-server`` service to apply the settings:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# service neutron-server restart
|
|
||||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 101 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 91 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 18 KiB |
@@ -1,23 +0,0 @@
|
|||||||
=================
|
|
||||||
Archived Contents
|
|
||||||
=================
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Contents here have been moved from the unified version of Administration
|
|
||||||
Guide. They will be merged into the Networking Guide gradually.
|
|
||||||
|
|
||||||
.. toctree::
|
|
||||||
:maxdepth: 2
|
|
||||||
|
|
||||||
introduction.rst
|
|
||||||
arch.rst
|
|
||||||
config-plugins.rst
|
|
||||||
config-agents.rst
|
|
||||||
config-identity.rst
|
|
||||||
adv-config.rst
|
|
||||||
multi-dhcp-agents.rst
|
|
||||||
use.rst
|
|
||||||
adv-features.rst
|
|
||||||
adv-operational-features.rst
|
|
||||||
auth.rst
|
|
||||||
@@ -1,186 +0,0 @@
|
|||||||
==========================
|
|
||||||
Introduction to Networking
|
|
||||||
==========================
|
|
||||||
|
|
||||||
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 NAT to edge firewalls, and IPsec VPN.
|
|
||||||
|
|
||||||
For a detailed description of the Networking API abstractions and their
|
|
||||||
attributes, see the `OpenStack Networking API v2.0
|
|
||||||
Reference <https://docs.openstack.org/api-ref/network/v2/>`__.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
If you use the Networking service, do not run the Compute
|
|
||||||
``nova-network`` service (like you do in traditional Compute deployments).
|
|
||||||
When you configure networking, see the Compute-related topics in this
|
|
||||||
Networking section.
|
|
||||||
|
|
||||||
Networking API
|
|
||||||
~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Networking is a virtual network service that provides a powerful API to
|
|
||||||
define the network connectivity and IP addressing that devices from
|
|
||||||
other services, such as Compute, use.
|
|
||||||
|
|
||||||
The Compute API has a virtual server abstraction to describe computing
|
|
||||||
resources. Similarly, the Networking API has virtual network, subnet,
|
|
||||||
and port abstractions to describe networking resources.
|
|
||||||
|
|
||||||
+---------------+-------------------------------------------------------------+
|
|
||||||
| Resource | Description |
|
|
||||||
+===============+=============================================================+
|
|
||||||
| **Network** | An isolated L2 segment, analogous to VLAN in the physical |
|
|
||||||
| | networking world. |
|
|
||||||
+---------------+-------------------------------------------------------------+
|
|
||||||
| **Subnet** | A block of v4 or v6 IP addresses and associated |
|
|
||||||
| | configuration state. |
|
|
||||||
+---------------+-------------------------------------------------------------+
|
|
||||||
| **Port** | A connection point for attaching a single device, such as |
|
|
||||||
| | the NIC of a virtual server, to a virtual network. Also |
|
|
||||||
| | describes the associated network configuration, such as |
|
|
||||||
| | the MAC and IP addresses to be used on that port. |
|
|
||||||
+---------------+-------------------------------------------------------------+
|
|
||||||
|
|
||||||
**Networking resources**
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
In particular, Networking supports each project having multiple private
|
|
||||||
networks and enables projects to choose their own IP addressing scheme,
|
|
||||||
even if those IP addresses overlap with those that other projects use.
|
|
||||||
|
|
||||||
The Networking service:
|
|
||||||
|
|
||||||
- Enables advanced cloud networking use cases, such as building
|
|
||||||
multi-tiered web applications and enabling migration of applications
|
|
||||||
to the cloud without changing IP addresses.
|
|
||||||
|
|
||||||
- Offers flexibility for administrators to customize network
|
|
||||||
offerings.
|
|
||||||
|
|
||||||
- Enables developers to extend the Networking API. Over time, the
|
|
||||||
extended functionality becomes part of the core Networking API.
|
|
||||||
|
|
||||||
Configure SSL support for networking API
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
OpenStack Networking supports SSL for the Networking API server. By
|
|
||||||
default, SSL is disabled but you can enable it in the ``neutron.conf``
|
|
||||||
file.
|
|
||||||
|
|
||||||
Set these options to configure SSL:
|
|
||||||
|
|
||||||
``use_ssl = True``
|
|
||||||
Enables SSL on the networking API server.
|
|
||||||
|
|
||||||
``ssl_cert_file = PATH_TO_CERTFILE``
|
|
||||||
Certificate file that is used when you securely start the Networking
|
|
||||||
API server.
|
|
||||||
|
|
||||||
``ssl_key_file = PATH_TO_KEYFILE``
|
|
||||||
Private key file that is used when you securely start the Networking
|
|
||||||
API server.
|
|
||||||
|
|
||||||
``ssl_ca_file = PATH_TO_CAFILE``
|
|
||||||
Optional. CA certificate file that is used when you securely start
|
|
||||||
the Networking API server. This file verifies connecting clients.
|
|
||||||
Set this option when API clients must authenticate to the API server
|
|
||||||
by using SSL certificates that are signed by a trusted CA.
|
|
||||||
|
|
||||||
``tcp_keepidle = 600``
|
|
||||||
The value of TCP\_KEEPIDLE, in seconds, for each server socket when
|
|
||||||
starting the API server. Not supported on OS X.
|
|
||||||
|
|
||||||
``retry_until_window = 30``
|
|
||||||
Number of seconds to keep retrying to listen.
|
|
||||||
|
|
||||||
``backlog = 4096``
|
|
||||||
Number of backlog requests with which to configure the socket.
|
|
||||||
|
|
||||||
Firewall-as-a-Service (FWaaS) overview
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
For information on Firewall-as-a-Service (FWaaS), please consult the
|
|
||||||
:doc:`Networking Guide <../fwaas>`.
|
|
||||||
|
|
||||||
Allowed-address-pairs
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
``Allowed-address-pairs`` enables you to specify
|
|
||||||
mac_address and ip_address(cidr) pairs that pass through a port regardless
|
|
||||||
of subnet. This enables the use of protocols such as VRRP, which floats
|
|
||||||
an IP address between two instances to enable fast data plane failover.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Currently, only the ML2 plug-in supports the allowed-address-pairs
|
|
||||||
extension.
|
|
||||||
|
|
||||||
**Basic allowed-address-pairs operations.**
|
|
||||||
|
|
||||||
- Create a port with a specified allowed address pair:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack port create port1 --allowed-address \
|
|
||||||
ip-address=<IP_CIDR>[,mac_address=<MAC_ADDRESS]
|
|
||||||
|
|
||||||
.. note:
|
|
||||||
The IP address IP_CIDR should belong to a Neutron port. In ML2/OVN, the
|
|
||||||
port with fixed IP IP_CIDR will be marked as "virtual" in the Northbound
|
|
||||||
"Logical_Switch_Port.type" register field. This virtual port cannot be
|
|
||||||
bound to a virtual machine:
|
|
||||||
|
|
||||||
- Update a port by adding allowed address pairs:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack port set PORT_UUID --allowed-address \
|
|
||||||
ip-address=<IP_CIDR>[,mac_address=<MAC_ADDRESS]
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Virtual-Private-Network-as-a-Service (VPNaaS)
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The VPNaaS extension enables OpenStack projects to extend private networks
|
|
||||||
across the internet.
|
|
||||||
|
|
||||||
VPNaaS is a service. It is a parent object that associates a VPN
|
|
||||||
with a specific subnet and router. Only one VPN service object can be
|
|
||||||
created for each router and each subnet. However, each VPN service object
|
|
||||||
can have any number of IP security connections.
|
|
||||||
|
|
||||||
The Internet Key Exchange (IKE) policy specifies the authentication and
|
|
||||||
encryption algorithms to use during phase one and two negotiation of a VPN
|
|
||||||
connection. The IP security policy specifies the authentication and encryption
|
|
||||||
algorithm and encapsulation mode to use for the established VPN connection.
|
|
||||||
Note that you cannot update the IKE and IPSec parameters for live tunnels.
|
|
||||||
|
|
||||||
You can set parameters for site-to-site IPsec connections, including peer
|
|
||||||
CIDRs, MTU, authentication mode, peer address, DPD settings, and status.
|
|
||||||
|
|
||||||
The current implementation of the VPNaaS extension provides:
|
|
||||||
|
|
||||||
- Site-to-site VPN that connects two private networks.
|
|
||||||
|
|
||||||
- Multiple VPN connections per project.
|
|
||||||
|
|
||||||
- IKEv1 policy support with 3des, aes-128, aes-256, or aes-192 encryption.
|
|
||||||
|
|
||||||
- IPSec policy support with 3des, aes-128, aes-192, or aes-256 encryption,
|
|
||||||
sha1 authentication, ESP, AH, or AH-ESP transform protocol, and tunnel or
|
|
||||||
transport mode encapsulation.
|
|
||||||
|
|
||||||
- Dead Peer Detection (DPD) with hold, clear, restart, disabled, or
|
|
||||||
restart-by-peer actions.
|
|
||||||
|
|
||||||
The VPNaaS driver plugin can be configured in the neutron configuration file.
|
|
||||||
You can then enable the service.
|
|
||||||
@@ -1,7 +0,0 @@
|
|||||||
=========================================
|
|
||||||
Scalable and highly available DHCP agents
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
This section is fully described at the
|
|
||||||
:doc:`High-availability for DHCP <../config-dhcp-ha>`
|
|
||||||
in the Networking Guide.
|
|
||||||
@@ -1,347 +0,0 @@
|
|||||||
==============
|
|
||||||
Use Networking
|
|
||||||
==============
|
|
||||||
|
|
||||||
You can manage OpenStack Networking services by using the service
|
|
||||||
command. For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# service neutron-server stop
|
|
||||||
# service neutron-server status
|
|
||||||
# service neutron-server start
|
|
||||||
# service neutron-server restart
|
|
||||||
|
|
||||||
Log files are in the ``/var/log/neutron`` directory.
|
|
||||||
|
|
||||||
Configuration files are in the ``/etc/neutron`` directory.
|
|
||||||
|
|
||||||
Administrators and projects can use OpenStack Networking to build
|
|
||||||
rich network topologies. Administrators can create network
|
|
||||||
connectivity on behalf of projects.
|
|
||||||
|
|
||||||
Core Networking API features
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
After installing and configuring Networking (neutron), projects and
|
|
||||||
administrators can perform create-read-update-delete (CRUD) API networking
|
|
||||||
operations. This is performed using the Networking API directly with either
|
|
||||||
the :command:`neutron` command-line interface (CLI) or the :command:`openstack`
|
|
||||||
CLI. The :command:`neutron` CLI is a wrapper around the Networking API. Every
|
|
||||||
Networking API call has a corresponding :command:`neutron` command.
|
|
||||||
|
|
||||||
The :command:`openstack` CLI is a common interface for all OpenStack
|
|
||||||
projects, however, not every API operation has been implemented. For the
|
|
||||||
list of available commands, see `Command List
|
|
||||||
<https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html>`__.
|
|
||||||
|
|
||||||
The :command:`neutron` CLI includes a number of options. For details, see
|
|
||||||
`Create and manage networks <https://docs.openstack.org/user-guide/cli-create-and-manage-networks.html>`__.
|
|
||||||
|
|
||||||
Basic Networking operations
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
To learn about advanced capabilities available through the :command:`neutron`
|
|
||||||
command-line interface (CLI), read the networking section `Create and manage
|
|
||||||
networks <https://docs.openstack.org/user-guide/cli-create-and-manage-networks.html>`__
|
|
||||||
in the OpenStack End User Guide.
|
|
||||||
|
|
||||||
This table shows example :command:`openstack` commands that enable you to
|
|
||||||
complete basic network operations:
|
|
||||||
|
|
||||||
+-------------------------+-------------------------------------------------+
|
|
||||||
| Operation | Command |
|
|
||||||
+=========================+=================================================+
|
|
||||||
|Creates a network. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack network create net1`` |
|
|
||||||
+-------------------------+-------------------------------------------------+
|
|
||||||
|Creates a subnet that is | |
|
|
||||||
|associated with net1. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack subnet create subnet1`` |
|
|
||||||
| | ``--subnet-range 10.0.0.0/24`` |
|
|
||||||
| | ``--network net1`` |
|
|
||||||
+-------------------------+-------------------------------------------------+
|
|
||||||
|Lists ports for a | |
|
|
||||||
|specified project. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack port list`` |
|
|
||||||
+-------------------------+-------------------------------------------------+
|
|
||||||
|Lists ports for a | |
|
|
||||||
|specified project | |
|
|
||||||
|and displays the ``ID``, | |
|
|
||||||
|``Fixed IP Addresses`` | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack port list -c ID`` |
|
|
||||||
| | ``-c "Fixed IP Addresses`` |
|
|
||||||
+-------------------------+-------------------------------------------------+
|
|
||||||
|Shows information for a | |
|
|
||||||
|specified port. | |
|
|
||||||
| | ``$ openstack port show PORT_ID`` |
|
|
||||||
+-------------------------+-------------------------------------------------+
|
|
||||||
|
|
||||||
**Basic Networking operations**
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The ``device_owner`` field describes who owns the port. A port whose
|
|
||||||
``device_owner`` begins with:
|
|
||||||
|
|
||||||
- ``network`` is created by Networking.
|
|
||||||
|
|
||||||
- ``compute`` is created by Compute.
|
|
||||||
|
|
||||||
Administrative operations
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
The administrator can run any :command:`openstack` command on behalf of
|
|
||||||
projects by specifying an Identity ``project`` in the command, as
|
|
||||||
follows:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network create --project PROJECT_ID NETWORK_NAME
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack network create --project 5e4bbe24b67a4410bc4d9fae29ec394e net1
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
To view all project IDs in Identity, run the following command as an
|
|
||||||
Identity service admin user:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack project list
|
|
||||||
|
|
||||||
Advanced Networking operations
|
|
||||||
------------------------------
|
|
||||||
|
|
||||||
This table shows example CLI commands that enable you to complete
|
|
||||||
advanced network operations:
|
|
||||||
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
| Operation | Command |
|
|
||||||
+===============================+============================================+
|
|
||||||
|Creates a network that | |
|
|
||||||
|all projects can use. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack network create`` |
|
|
||||||
| | ``--share public-net`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|Creates a subnet with a | |
|
|
||||||
|specified gateway IP address. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack subnet create subnet1`` |
|
|
||||||
| | ``--gateway 10.0.0.254 --network net1`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|Creates a subnet that has | |
|
|
||||||
|no gateway IP address. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack subnet create subnet1`` |
|
|
||||||
| | ``--no-gateway --network net1`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|Creates a subnet with DHCP | |
|
|
||||||
|disabled. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack subnet create subnet1`` |
|
|
||||||
| | ``--network net1 --no-dhcp`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|Specifies a set of host routes | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack subnet create subnet1`` |
|
|
||||||
| | ``--network net1 --host-route`` |
|
|
||||||
| | ``destination=40.0.1.0/24,`` |
|
|
||||||
| | ``gateway=40.0.0.2`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|Creates a subnet with a | |
|
|
||||||
|specified set of dns name | |
|
|
||||||
|servers. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack subnet create subnet1`` |
|
|
||||||
| | ``--network net1 --dns-nameserver`` |
|
|
||||||
| | ``8.8.4.4`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|Displays all ports and | |
|
|
||||||
|IPs allocated on a network. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack port list --network NET_ID`` |
|
|
||||||
+-------------------------------+--------------------------------------------+
|
|
||||||
|
|
||||||
**Advanced Networking operations**
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
During port creation and update, specific extra-dhcp-options can be left blank.
|
|
||||||
For example, ``router`` and ``classless-static-route``. This causes dnsmasq
|
|
||||||
to have an empty option in the ``opts`` file related to the network.
|
|
||||||
For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
tag:tag0,option:classless-static-route,
|
|
||||||
tag:tag0,option:router,
|
|
||||||
|
|
||||||
Use Compute with Networking
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Basic Compute and Networking operations
|
|
||||||
---------------------------------------
|
|
||||||
|
|
||||||
This table shows example :command:`openstack` commands that enable you to
|
|
||||||
complete basic VM networking operations:
|
|
||||||
|
|
||||||
+----------------------------------+-----------------------------------------+
|
|
||||||
| Action | Command |
|
|
||||||
+==================================+=========================================+
|
|
||||||
|Checks available networks. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack network list`` |
|
|
||||||
+----------------------------------+-----------------------------------------+
|
|
||||||
|Boots a VM with a single NIC on | |
|
|
||||||
|a selected Networking network. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack server create --image`` |
|
|
||||||
| | ``IMAGE --flavor FLAVOR --nic`` |
|
|
||||||
| | ``net-id=NET_ID VM_NAME`` |
|
|
||||||
+----------------------------------+-----------------------------------------+
|
|
||||||
|Searches for ports with a | |
|
|
||||||
|``device_id`` that matches the | |
|
|
||||||
|Compute instance UUID. See :ref: | |
|
|
||||||
|`Create and delete VMs` | |
|
|
||||||
| | |
|
|
||||||
| |``$ openstack port list --server VM_ID`` |
|
|
||||||
+----------------------------------+-----------------------------------------+
|
|
||||||
|Searches for ports, but shows | |
|
|
||||||
|only the ``mac_address`` of | |
|
|
||||||
|the port. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack port list -c`` |
|
|
||||||
| | ``"MAC Address" --server VM_ID`` |
|
|
||||||
+----------------------------------+-----------------------------------------+
|
|
||||||
|Temporarily disables a port from | |
|
|
||||||
|sending traffic. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack port set PORT_ID`` |
|
|
||||||
| | ``--disable`` |
|
|
||||||
+----------------------------------+-----------------------------------------+
|
|
||||||
|
|
||||||
**Basic Compute and Networking operations**
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The ``device_id`` can also be a logical router ID.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
- When you boot a Compute VM, a port on the network that
|
|
||||||
corresponds to the VM NIC is automatically created and associated
|
|
||||||
with the default security group. You can configure `security
|
|
||||||
group rules <#enable-ping-and-ssh-on-vms-security-groups>`__ to enable
|
|
||||||
users to access the VM.
|
|
||||||
|
|
||||||
.. _Create and delete VMs:
|
|
||||||
- When you delete a Compute VM, the underlying Networking port is
|
|
||||||
automatically deleted.
|
|
||||||
|
|
||||||
Advanced VM creation operations
|
|
||||||
-------------------------------
|
|
||||||
|
|
||||||
This table shows example :command:`openstack` commands that enable you to
|
|
||||||
complete advanced VM creation operations:
|
|
||||||
|
|
||||||
+-------------------------------------+--------------------------------------+
|
|
||||||
| Operation | Command |
|
|
||||||
+=====================================+======================================+
|
|
||||||
|Boots a VM with multiple | |
|
|
||||||
|NICs. | |
|
|
||||||
| | ``$ openstack server create --image``|
|
|
||||||
| | ``IMAGE --flavor FLAVOR --nic`` |
|
|
||||||
| | ``net-id=NET_ID VM_NAME`` |
|
|
||||||
| | ``net-id=NET2-ID VM_NAME`` |
|
|
||||||
+-------------------------------------+--------------------------------------+
|
|
||||||
|Boots a VM with a specific IP | |
|
|
||||||
|address. Note that you cannot | |
|
|
||||||
|use the ``--max`` or ``--min`` | |
|
|
||||||
|parameters in this case. | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack server create --image``|
|
|
||||||
| | ``IMAGE --flavor FLAVOR --nic`` |
|
|
||||||
| | ``net-id=NET_ID VM_NAME`` |
|
|
||||||
| | ``v4-fixed-ip=IP-ADDR VM_NAME`` |
|
|
||||||
+-------------------------------------+--------------------------------------+
|
|
||||||
|Boots a VM that connects to all | |
|
|
||||||
|networks that are accessible to the | |
|
|
||||||
|project who submits the request | |
|
|
||||||
|(without the ``--nic`` option). | |
|
|
||||||
| | |
|
|
||||||
| | ``$ openstack server create --image``|
|
|
||||||
| | ``IMAGE --flavor FLAVOR`` |
|
|
||||||
+-------------------------------------+--------------------------------------+
|
|
||||||
|
|
||||||
**Advanced VM creation operations**
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Cloud images that distribution vendors offer usually have only one
|
|
||||||
active NIC configured. When you boot with multiple NICs, you must
|
|
||||||
configure additional interfaces on the image or the NICs are not
|
|
||||||
reachable.
|
|
||||||
|
|
||||||
The following Debian/Ubuntu-based example shows how to set up the
|
|
||||||
interfaces within the instance in the ``/etc/network/interfaces``
|
|
||||||
file. You must apply this configuration to the image.
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
# The loopback network interface
|
|
||||||
auto lo
|
|
||||||
iface lo inet loopback
|
|
||||||
|
|
||||||
auto eth0
|
|
||||||
iface eth0 inet dhcp
|
|
||||||
|
|
||||||
auto eth1
|
|
||||||
iface eth1 inet dhcp
|
|
||||||
|
|
||||||
Enable ping and SSH on VMs (security groups)
|
|
||||||
--------------------------------------------
|
|
||||||
|
|
||||||
You must configure security group rules depending on the type of plug-in
|
|
||||||
you are using. If you are using a plug-in that:
|
|
||||||
|
|
||||||
- Implements Networking security groups, you can configure security
|
|
||||||
group rules directly by using the :command:`openstack security group rule create`
|
|
||||||
command. This example enables ``ping`` and ``ssh`` access to your VMs.
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group rule create --protocol icmp \
|
|
||||||
--ingress SECURITY_GROUP
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group rule create --protocol tcp \
|
|
||||||
--egress --description "Sample Security Group" SECURITY_GROUP
|
|
||||||
|
|
||||||
- Does not implement Networking security groups, you can configure
|
|
||||||
security group rules by using the :command:`openstack security group rule
|
|
||||||
create` or :command:`euca-authorize` command. These :command:`openstack`
|
|
||||||
commands enable ``ping`` and ``ssh`` access to your VMs.
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ openstack security group rule create --protocol icmp default
|
|
||||||
$ openstack security group rule create --protocol tcp --dst-port 22:22 default
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
If your plug-in implements Networking security groups, you can also
|
|
||||||
leverage Compute security groups by setting
|
|
||||||
``use_neutron = True`` in the ``nova.conf`` file. After
|
|
||||||
you set this option, all Compute security group commands are proxied
|
|
||||||
to Networking.
|
|
||||||
@@ -50,8 +50,6 @@ topology creation. To perform this task, proceed with the following steps:
|
|||||||
|
|
||||||
#. Set up a default external network
|
#. Set up a default external network
|
||||||
|
|
||||||
Setting up an external network is described in
|
|
||||||
`OpenStack Networking Guide <./archives/adv-features.html>`_.
|
|
||||||
Assuming the external network to be used for the auto-allocation feature
|
Assuming the external network to be used for the auto-allocation feature
|
||||||
is named ``public``, make it the ``default`` external network
|
is named ``public``, make it the ``default`` external network
|
||||||
with the following command:
|
with the following command:
|
||||||
|
|||||||
@@ -20,4 +20,3 @@ manage OpenStack Networking (neutron).
|
|||||||
migration
|
migration
|
||||||
misc
|
misc
|
||||||
ovn/index
|
ovn/index
|
||||||
archives/index
|
|
||||||
|
|||||||
@@ -246,7 +246,7 @@ For example::
|
|||||||
Provider Networking
|
Provider Networking
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
Neutron can also be configured to create `provider networks <../../admin/archives/adv-features.html#provider-networks>`_.
|
Neutron can also be configured to create provider networks.
|
||||||
|
|
||||||
L3 agent extensions
|
L3 agent extensions
|
||||||
-------------------
|
-------------------
|
||||||
|
|||||||
Reference in New Issue
Block a user