DOCSEARCHbyAlgolia
Submit Docs

OpenStack Neutron Documentation

repository·master·Indexed 23 days ago

https://github.com/openstack/neutron

Core networking service for OpenStack providing connectivity as a service to virtual machines. This documentation includes a feature matrix comparing OVS and OVN backends across Core L3, BGP Dynamic Routing, BGP/MPLS VPN, VPNaaS, FWaaS v2, SFC, and TaaS. It also provides technical guidance on the neutron-keepalived-state-change CLI script and configuring active-active L3 gateways with multihoming.

Tokens
216.8K
Snippets
353
Records
1K
Agent score
80%

What's inside OpenStack Neutron

  1. What is OpenStack Networking (Neutron)?

    master
    OpenStack Networking (Neutron) is a standalone service that provides an API for defining and managing network connectivity and addressing in a cloud environment. It manages virtual networking infrastructure, including networks, switches, subnets, and routers for devices managed by OpenStack Compute (nova). It can also support advanced services like firewalls and Virtual Private Networks (VPNs).

  2. Overview of OpenStack Networking (Neutron)

    master

    OpenStack Networking, code-named neutron, provides an API for defining network connectivity and addressing in the cloud. It allows operators to manage network objects like networks, subnets, and ports, and supports a wide range of services including L3 forwarding, Network Address Translation (NAT), perimeter firewalls, and virtual private networks.

    Key architectural components include:

    • API server: Supports Layer 2 networking and IP Address Management (IPAM). It includes an extension for Layer 3 router constructs to enable routing between Layer 2 networks and external gateways. It uses plug-ins to interoperate with various technologies like routers, switches, virtual switches, and SDN controllers.
    • Plug-in and agents: Responsible for physical/virtual actions such as plugging/unplugging ports, creating networks or subnets, and providing IP addressing. Note that only one plug-in can be used at a time.
    • Messaging queue: Handles RPC (Remote Procedure Call) requests between agents to complete API operations. In the ML2 (Modular Layer 2) plug-in, the message queue facilitates RPC between the neutron server and the neutron agents running on hypervisors (e.g., for Open vSwitch or OVN).

  3. Overview of OpenStack Neutron

    master
    OpenStack Neutron is a project designed to provide "network connectivity as a service" between interface devices (such as vNICs) that are managed by other OpenStack services like Nova. It acts as the networking component of the OpenStack ecosystem, enabling connectivity for cloud resources.

  4. Identify Neutron Core Reviewer Teams and Repositories

    master

    Neutron's governance is divided into several core reviewer teams, each with specific repository access and responsibilities:

    • Neutron Core Reviewer Team: Has merge rights to openstack/neutron and openstack/python-neutronclient.
    • Core Reviewer Teams for Plugins and Drivers: Associated with specific driver repositories (as listed in the Neutron project team reference). These teams manage their own specs, RFEs, and features but remain under the oversight and veto of the Neutron PTL.
    • Neutron Specs Core Reviewer Team: Has +2 rights to openstack/neutron-specs. They review specifications for all Neutron repositories (including Advanced Services) and focus on architectural impact and development capacity.
    • Drivers Team: Has full rights to the specs repository. They ensure architectural consistency, review and comment on RFEs (Request for Feature Enhancement), and provide guidance to specification contributors. They meet regularly to discuss the project roadmap.
    • Release Team: Holds specialized Gerrit permissions for release management of Neutron sub-projects, including pushing signed tags, pushing merge commits, and approving changes across all Neutron git repositories to unblock release activities.

  5. Understand the structure of Rally job files

    master

    The rally-jobs/ directory contains Rally tasks and plugins used by OpenStack CI. The directory structure is organized as follows:

    • plugins/: A directory for adding Rally plugins. In Rally, most components are plugins, including Benchmark contexts, Benchmark scenarios, SLA checks, and Generic cleanup resources.
    • extra/: Files in this directory are copied to gates. This allows Rally tasks to use absolute paths for these files, which will be located at ~/.rally/extra/* on the execution environment.
    • neutron-neutron.yaml: A specific task designed to be run in gates against OpenStack environments where the Neutron Service is deployed via DevStack.

  6. Understand the OpenStack Example Architecture for Proof-of-Concept

    master

    This guide describes a minimum configuration architecture designed for learning and proof-of-concept (PoC) purposes. It is not intended for production use.

    Key characteristics of this PoC architecture include:

    • Networking Agents: Reside on the controller node rather than dedicated network nodes.
    • Overlay Traffic: Self-service network tunnel traffic traverses the management network instead of a dedicated network.
    • Node Requirements: Requires at least two nodes to launch a basic virtual machine (VM). Additional nodes are needed for optional services like Block Storage and Object Storage.

    To move toward a production environment, you should implement redundancy, increase security (firewalls, encryption), and use automation tools like Ansible, Chef, Puppet, or Salt.

  7. Locate Neutron documentation by type

    master

    Neutron documentation is organized into specific directories based on the target audience and content type:

    • Operator/Admin Docs: doc/source/admin/ (feature-specific configuration).
    • Configuration Stubs: doc/source/configuration (auto-generated config files).
    • Developer Internals: doc/source/contributor/internals (low-level technical details).
    • Policies: doc/source/contributor/policies (team policies and best practices).
    • Installation: doc/source/install (setting up network-enabled nodes).
    • API Reference: Located in the neutron-lib repository (api-ref) for resource and extension details.

  8. Find Neutron documentation by type

    master

    Neutron documentation is categorized in the doc/source/ directory:

    • Operator Guides: doc/source/admin/ (deployment, configuration, architecture).
    • Developer Guides: doc/source/contributor/ (process, testing, internals).
    • ML2/OVN Specifics: doc/source/ovn/ (gaps, FAQ, tracing).
    • Installation: doc/source/install/ (controller and compute nodes).
    • Configuration Reference: doc/source/configuration/ (auto-generated).
    • CLI Reference: doc/source/cli/ (command-line tool reference).

  9. Locate the Neutron Networking API reference

    master
    The Networking API reference for Neutron is not maintained within this repository. It is maintained in the neutron-lib repository. To access the API documentation, navigate to the api-ref directory in the neutron-lib repository.

  10. Configure a host for Neutron functional and fullstack tests

    master

    This role configures a host to serve as an environment for running Neutron functional and fullstack tests. It relies on several Ansible role variables to define the test environment, including the virtual environment, project directory, and paths for DevStack and Neutron source code.

    Role Variables

    VariableDefault ValueDescription
    tests_venv{{ tox_envlist }}The virtual environment used for tests.
    project_nameneutronThe name of the project.
    base_dir{{ ansible_user_dir }}/src/opendev.orgThe base directory for OpenDev projects.
    gate_dest_dir{{ base_dir }}/openstackThe destination directory for the gate/openstack repository.
    devstack_dir{{ base_dir }}/openstack/devstackThe directory where DevStack is located.
    neutron_dir{{ gate_dest_dir }}/neutronThe directory containing the Neutron source code.

  11. Manage Networking service quotas

    master

    Quotas in Neutron limit the number of available resources a project can create. When a project attempts to exceed its assigned quota, Neutron returns a ConflictException: 409 error.

    Example error:

    $ openstack network create test_net
Error while executing command: ConflictException: 409, Quota exceeded for resources: ['network'].

    By default, the Networking service applies the same quota values to all projects. These values are configured globally in the Neutron configuration file. Per-project quota configuration is also supported via the quota extension API.

  12. What is Private VLAN (PVLAN) and how do port types work?

    master

    Private VLAN (PVLAN) is a device isolation mechanism that uses forwarding constraints to control communication between ports on a network.

    Every port on a PVLAN-enabled network is assigned one of three types:

    • Promiscuous: Can communicate with any other port on the network. This is the default type if no --pvlan-type is specified.
    • Isolated: Can communicate only with promiscuous ports. Isolated ports cannot communicate with each other.
    • Community: Can communicate with other ports in the same named community and with promiscuous ports. This requires a --pvlan-community name.

    Note: Security groups are compatible with PVLAN ports and act as a layer below PVLAN. Special ports like metadata ports will always be promiscuous.